* Re: [PATCH v2 0/5] netfilter: nf_flow_table_path: L2 bridge offload
From: Pablo Neira Ayuso @ 2026-06-30 8:45 UTC (permalink / raw)
To: Daniel Pawlik
Cc: netfilter-devel, netdev, fw, phil, davem, edumazet, kuba, pabeni,
horms, andrew+netdev, razor, idosch, matthias.bgg,
angelogioacchino.delregno, bridge, coreteam, linux-mediatek,
linux-arm-kernel, rchen14b, lorenzo
In-Reply-To: <20260630065735.3341614-1-pawlik.dan@gmail.com>
Hi,
On Tue, Jun 30, 2026 at 08:57:30AM +0200, Daniel Pawlik wrote:
> This series adds L2 bridge offload support to nft_flow_offload, allowing
> bridged IPv4/IPv6 flows to be accelerated by the flowtable fast path
> without requiring L3 routing.
>
> Background
> ----------
> Hardware flow offload engines (e.g. MediaTek PPE) can accelerate bridged
> traffic but require that nft_flow_offload detect and handle bridged flows
> differently from routed ones: no routing table lookup, MAC addresses from
> the Ethernet header, and VLAN context pre-populated from the bridge port.
>
> v2: Fix missing Returns: tags in kernel-doc comments for the three new
> bridge helpers (br_fdb_has_forwarding_entry_rcu,
> br_vlan_get_offload_info_rcu, br_vlan_is_enabled_rcu).
>
> Patches
> -------
> 1/5 net: export __dev_fill_forward_path
> Refactors dev_fill_forward_path() to expose __dev_fill_forward_path()
> which accepts a caller-supplied net_device_path_ctx, needed to
> pre-populate VLAN state before the forward path walk.
>
> 2/5 net: bridge: add flow offload helpers
> Adds br_fdb_has_forwarding_entry_rcu(), br_vlan_get_offload_info_rcu()
> and br_vlan_is_enabled_rcu() to expose bridge state to nft_flow_offload
> without requiring inclusion of net/bridge/br_private.h.
>
> 3/5 netfilter: nf_flow_table_path: add L2 bridge offload
> Core of the series. Adds nft_flow_offload_is_bridging() detection,
> nft_flow_route_bridging() which avoids nf_route() (fails for
> bridged-only subnets), MAC/VLAN pre-population for bridged flows,
> and a dst leak fix. nft_flow_route() becomes a thin dispatcher.
>
> 4/5 netfilter: nf_flow_table_path: handle DEV_PATH_MTK_WDMA in path info
> Fixes zero-source-MAC in PPE entries when a bridged flow traverses
> MT7996/MT7915 WiFi WDMA hardware.
>
> 5/5 netfilter: nf_flow_table_path: add VLAN passthrough support
> Records VLAN encap info for passthrough-mode bridge ports so hardware
> offload entries include the correct VLAN tag.
>
> Rebase note
> -----------
> Originally developed against OpenWrt pending-6.18 patches by Ryan Chen
> <rchen14b@gmail.com> and Bo-Cun Chen <bc-bocun.chen@mediatek.com>.
> Rebased to current upstream: path discovery infrastructure moved to
> nf_flow_table_path.c in commit 93d7a7ed0734 ("netfilter: flowtable: move
> path discovery infrastructure to its own file"), so all netfilter changes
> now land in that file rather than nft_flow_offload.c.
>
> How to enable bridge offload
> -----------------------------
> 1. Load kmod-br-netfilter so that bridged IP traffic traverses the
> netfilter forward chain.
>
> 2. Enable netfilter hooks on the bridge:
> echo 1 > /sys/class/net/<br>/bridge/nf_call_iptables
> echo 1 > /sys/class/net/<br>/bridge/nf_call_ip6tables
This requires br_netfilter which is a no go.
Sorry, but we should really target at the native nf_conntrack_bridge
support.
> 3. Register bridge member interfaces in the nft flowtable:
> table inet filter {
> flowtable f {
> hook ingress priority filter
> devices = { eth0, wlan0 }
> }
> chain forward {
> type filter hook forward priority filter
> meta l4proto { tcp, udp } flow add @f
> }
> }
Yes, but br_netfilter makes no sense for nftables.
br_netfilter was made to fill gap at the time ebtables was lagging a
lot behind iptables in terms of features. And getting ebtables on pair
with iptables in functionality was not feasible either, because it
required many new extensions that were specific of the bridge family,
which probably was not a big deal, but it also required to get
the ebtables command line tool on pair with iptables userspace, which
has received more development attention/effort that the bridge tool.
All of this does not stand true anymore with nftables, where the
bridge family capabilities are at pair with the inet families.
I am looking now at the native flowtable bridge support, I will get
back to you with updates.
^ permalink raw reply
* Re: [PATCH RFC v5 11/12] reset: zte: Add a zx297520v3 reset driver
From: Philipp Zabel @ 2026-06-30 8:45 UTC (permalink / raw)
To: Stefan Dösinger, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260628-zx29clk-v5-11-79ff044e4192@gmail.com>
On So, 2026-06-28 at 22:59 +0300, Stefan Dösinger wrote:
> This drives the MFD child devices created by the zx297520v3-crm driver
> as well as the aux device created by the zx297520v3-lspclk driver.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> v5:
> Make top and matrix MFD children instead of aux devices
Why? What is the difference between top/matrix and lsp here?
Couldn't you just keep all three as aux devices and remove the
platform_device boilerplate half of the driver?
[...]
> diff --git a/drivers/reset/reset-zte-zx297520v3.c b/drivers/reset/reset-zte-zx297520v3.c
> new file mode 100644
> index 000000000000..8ef434904230
> --- /dev/null
> +++ b/drivers/reset/reset-zte-zx297520v3.c
> @@ -0,0 +1,274 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Stefan Dösinger
> + */
> +#include <dt-bindings/reset/zte,zx297520v3-reset.h>
> +#include <linux/reset-controller.h>
> +#include <linux/platform_device.h>
> +#include <linux/auxiliary_bus.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/iopoll.h>
Looks like this is not needed anymore.
> +/* Most devices on the zx297520v3 SoC have one reset bit per clock line. As a rule of thumb, the
> + * lower bit disconnects the device from the bus, similarly to turning off PCLK - registers read 0
> + * or hang indefinitely. Unlike PCLK, this reset may have a lingering effect after deasserting.
> + * E.g. timers will be disabled, but retain their counter value.
> + *
> + * The other bit resets the actual device registers.
> + *
> + * For some devices, e.g. GMAC, the reset bits behave in the same way: They disconnect the device
> + * and registers will have their default state after deasserting. For devices that have both reset
> + * bits, both need to be deasserted for the device to function.
> + */
> +struct zte_reset_reg {
> + u32 mask;
> + u16 reg;
> +};
> +
> +struct zte_reset_info {
> + const struct zte_reset_reg *resets;
> + unsigned int num;
> +};
> +
> +struct zte_reset {
> + struct reset_controller_dev rcdev;
> + struct regmap *map;
> + const struct zte_reset_reg *resets;
> +};
> +
> +static inline struct zte_reset *to_zte_reset(struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct zte_reset, rcdev);
> +}
> +
> +static int zx29_rst_assert(struct reset_controller_dev *rcdev, unsigned long id)
> +{
> + struct zte_reset *rst = to_zte_reset(rcdev);
> +
> + return regmap_clear_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
> +}
> +
> +static int zx29_rst_deassert(struct reset_controller_dev *rcdev, unsigned long id)
> +{
> + struct zte_reset *rst = to_zte_reset(rcdev);
> +
> + return regmap_set_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
> +}
> +
> +static int zx29_rst_status(struct reset_controller_dev *rcdev, unsigned long id)
> +{
> + struct zte_reset *rst = to_zte_reset(rcdev);
> + int res;
> +
> + res = regmap_test_bits(rst->map, rst->resets[id].reg, rst->resets[id].mask);
The correct thing to do here would be to only check the reset bit.
This happens to work anyway because we always set reset and isolation
bits together, but maybe this warrants a comment.
I assume the registers just read back the value that was set.
> + if (res < 0)
> + return res;
> +
> + return !res;
> +}
> +
[...]
> +static int reset_zx297520v3_common_probe(struct device *dev,
> + struct device_node *of_node,
> + const struct zte_reset_info *drv_info)
> +{
> + struct zte_reset *rst;
> +
> + rst = devm_kzalloc(dev, sizeof(*rst), GFP_KERNEL);
> + if (!rst)
> + return -ENOMEM;
> +
> + rst->resets = drv_info->resets;
> + rst->rcdev.owner = THIS_MODULE;
> + rst->rcdev.nr_resets = drv_info->num;
> + rst->rcdev.ops = &zx29_rst_ops;
> + rst->rcdev.of_node = of_node;
> + rst->rcdev.dev = dev;
> +
> + rst->map = device_node_to_regmap(of_node);
> + if (IS_ERR(rst->map))
> + return dev_err_probe(dev, PTR_ERR(rst->map), "Cannot get parent syscon regmap\n");
> +
> + return devm_reset_controller_register(dev, &rst->rcdev);
> +
Unnecessary blank line.
> +}
> +
> +static int reset_zx297520v3_aux_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + return reset_zx297520v3_common_probe(&adev->dev, adev->dev.of_node,
> + (const struct zte_reset_info *)id->driver_data);
> +}
> +
> +static int reset_zx297520v3_top_probe(struct platform_device *pdev)
> +{
> + return reset_zx297520v3_common_probe(&pdev->dev, pdev->dev.parent->of_node,
> + &zx297520v3_top_info);
> +}
> +
> +static struct platform_driver reset_zx297520v3_top = {
> + .probe = reset_zx297520v3_top_probe,
> + .driver = {
> + .name = "zx297520v3-toprst",
> + },
> +};
> +
> +static int reset_zx297520v3_matrix_probe(struct platform_device *pdev)
> +{
> + return reset_zx297520v3_common_probe(&pdev->dev, pdev->dev.parent->of_node,
> + &zx297520v3_matrix_info);
> +}
> +
> +static struct platform_driver reset_zx297520v3_matrix = {
> + .probe = reset_zx297520v3_matrix_probe,
> + .driver = {
> + .name = "zx297520v3-matrixrst",
> + },
> +};
> +
> +static const struct auxiliary_device_id reset_zx297520v3_ids[] = {
> + {
> + .name = "clk_zte.zx297520v3_lsprst",
> + .driver_data = (kernel_ulong_t)&zx297520v3_lsp_info,
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(auxiliary, reset_zx297520v3_ids);
> +
> +static struct auxiliary_driver reset_zx297520v3_auxdrv = {
> + .name = "zx297520v3_lsp_reset",
> + .id_table = reset_zx297520v3_ids,
> + .probe = reset_zx297520v3_aux_probe,
> +};
> +
> +static struct platform_driver * const reset_zx297520v3_mfddrv[] = {
> + &reset_zx297520v3_top,
> + &reset_zx297520v3_matrix,
> +};
> +
> +static int __init reset_zx297520v3_init(void)
> +{
> + int res;
> +
> + res = auxiliary_driver_register(&reset_zx297520v3_auxdrv);
> + if (res)
> + return res;
> +
> + res = platform_register_drivers(reset_zx297520v3_mfddrv,
> + ARRAY_SIZE(reset_zx297520v3_mfddrv));
> + if (res)
> + auxiliary_driver_unregister(&reset_zx297520v3_auxdrv);
> +
> + return res;
> +}
> +
> +static void __exit reset_zx297520v3_exit(void)
> +{
> + platform_unregister_drivers(reset_zx297520v3_mfddrv,
> + ARRAY_SIZE(reset_zx297520v3_mfddrv));
> + auxiliary_driver_unregister(&reset_zx297520v3_auxdrv);
> +}
> +
> +module_init(reset_zx297520v3_init);
> +module_exit(reset_zx297520v3_exit);
That's too much boilerplate given I don't understand the benefit of
using platform_device for top/matrix resets yet.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-30 8:42 UTC (permalink / raw)
To: Leo Yan, Suzuki K Poulose, Mike Leach, James Clark
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Yuanfang Zhang, linux-arm-msm, devicetree,
linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <20260630081021.GD1812158@e132581.arm.com>
Hi Leo,
On 6/30/2026 4:10 PM, Leo Yan wrote:
> Hi Jie,
>
> On Tue, Jun 30, 2026 at 09:03:52AM +0800, Jie Gan wrote:
>
> [...]
>
>>> - How can you guarantee that a interconnect TraceNoC will never
>>> require ATID in the future?
>
>> From a hardware perspective, there is no fundamental difference between an
>> itnoc and an AG TraceNoC. They use the same TraceNoC hardware implementation
>> and share the same AMBA bus type. The distinction is purely functional: an
>> itnoc is used for local trace aggregation within a subsystem, whereas an AG
>> TraceNoC serves as the top-level aggregation point for the SoC.
>
> I'm still not convinced that adding "arm,primecell-periphid" is the
> right approach.
>
I agree we shouldn't need to add arm,primecell-periphid for the AMBA
bus, as the hardware provides the necessary registers to read the
peripheral ID. I used it as a temporary workaround to resolve the issue,
but I believe that solution is not correct.
> From the description above, I'd expect either the hardware to expose
> bits in a register to distinguish these two module types, or as I
> suggested earlier, to use a DT property to indicate the module type (or
> whether ATID is required).
>
I wanna distinguish the aggregator traceNoC and interconnect traceNoC,
even probe with platform driver, but the existing compatible is too
specific to the interconnect traceNoC device(coresight-itnoc), that's
why I didnt try the DT property proposal.
> Or have you tried to detect the last tnoc on a path and allocate ID for
> it? (You can retrieve csdev->path).
As Suzuki mentioned in the other thread, I think it would be better to
add separate compatibles in the of_match_table to distinguish between
Aggregator TraceNoC and Interconnect TraceNoC when probing with the
platform driver. This would allow us to allocate an ATID only for
Aggregator TraceNoC during probe, which is consistent with our original
design.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* [PATCH v2 5/9] ARM: VDSO: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-06-30 7:38 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-0-520d194640dd@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
arch/arm/vdso/vdso.lds.S | 2 ++
arch/arm/vdso/vgettimeofday.c | 14 ++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/vdso/vdso.lds.S b/arch/arm/vdso/vdso.lds.S
index 74d8d8bc8a40..e61038c0195a 100644
--- a/arch/arm/vdso/vdso.lds.S
+++ b/arch/arm/vdso/vdso.lds.S
@@ -70,9 +70,11 @@ VERSION
{
LINUX_2.6 {
global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
__vdso_clock_gettime;
__vdso_gettimeofday;
__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
__vdso_clock_gettime64;
__vdso_clock_getres_time64;
local: *;
diff --git a/arch/arm/vdso/vgettimeofday.c b/arch/arm/vdso/vgettimeofday.c
index f7a2f5dc2fdc..3eebeddbfd18 100644
--- a/arch/arm/vdso/vgettimeofday.c
+++ b/arch/arm/vdso/vgettimeofday.c
@@ -10,16 +10,17 @@
#include <asm/unwind.h>
#include <vdso/gettime.h>
+#ifdef CONFIG_COMPAT_32BIT_TIME
int __vdso_clock_gettime(clockid_t clock,
struct old_timespec32 *ts)
{
return __cvdso_clock_gettime32(clock, ts);
}
-int __vdso_clock_gettime64(clockid_t clock,
- struct __kernel_timespec *ts)
+int __vdso_clock_getres(clockid_t clock_id,
+ struct old_timespec32 *res)
{
- return __cvdso_clock_gettime(clock, ts);
+ return __cvdso_clock_getres_time32(clock_id, res);
}
int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
@@ -27,11 +28,12 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
{
return __cvdso_gettimeofday(tv, tz);
}
+#endif /* CONFIG_COMPAT_32BIT_TIME */
-int __vdso_clock_getres(clockid_t clock_id,
- struct old_timespec32 *res)
+int __vdso_clock_gettime64(clockid_t clock,
+ struct __kernel_timespec *ts)
{
- return __cvdso_clock_getres_time32(clock_id, res);
+ return __cvdso_clock_gettime(clock, ts);
}
int __vdso_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res)
--
2.55.0
^ permalink raw reply related
* Re: [PATCH RFC v5 05/12] clk: zte: Add Clock registration infrastructure.
From: Philipp Zabel @ 2026-06-30 8:27 UTC (permalink / raw)
To: Stefan Dösinger, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260628-zx29clk-v5-5-79ff044e4192@gmail.com>
On So, 2026-06-28 at 22:59 +0300, Stefan Dösinger wrote:
> The next patches will implement the regmap clocks and PLL driver. The
> actual hardware specific clock listing will live in a separate module.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> Version 5:
>
> *) Pass the static clk data instead of calling get_match_data to prepare
> for operating as an MFD child.
I think the MFD driver is unnecessary overhead. Can't you just keep the
reset controllers as auxdev and use of_platform_populate() to create
devices for clock-controller child nodes such as syscon-reboot?
> *) Don't use devm_kzalloc to allocate the auxiliary_device
> structure. I guess Sashiko is right, and that's what "Because once the
> device is placed on the bus the parent driver can not tell what other
> code may have a reference to this data" is trying to dell me.
Not using devm_kzalloc() for the auxdev is correct, but it looks like
you could simplify its creation a lot by just using
devm_auxiliary_device_create().
regards
Philipp
^ permalink raw reply
* Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain
From: Leo Yan @ 2026-06-30 8:23 UTC (permalink / raw)
To: Namhyung Kim
Cc: Arnaldo Carvalho de Melo, John Garry, Will Deacon, James Clark,
Mike Leach, Suzuki K Poulose, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov, linux-arm-kernel, coresight, linux-perf-users,
Leo Yan
In-Reply-To: <akMPoLNBbAEyNU64@google.com>
Hi Namhyung,
On Mon, Jun 29, 2026 at 05:36:48PM -0700, Namhyung Kim wrote:
[...]
> Will you send a new version or want to merge this? It seems there are
> some remaining comments from Sashiko.
I prefer to merge this series.
Sashiko reported several critical issues in the common code, they are on
my to-do list.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Suzuki K Poulose @ 2026-06-30 8:21 UTC (permalink / raw)
To: Jie Gan, Leo Yan, Mike Leach, James Clark
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Yuanfang Zhang, linux-arm-msm, devicetree,
linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <adb45638-1787-45cd-b4fd-d957323cc608@oss.qualcomm.com>
On 30/06/2026 02:03, Jie Gan wrote:
>
>
> On 6/29/2026 10:28 PM, Leo Yan wrote:
>> On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote:
>>
>> [...]
>>
>>> Can I fix the issue by adding "arm,primecell-periphid" property. That's
>>> would be the best temp solution as it avoids breaking the original
>>> design of
>>> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver.
>>
>> Before proceeding with the "arm,primecell-periphid" property, could you
>> clarify a bit:
>>
>> - For an interconnect TraceNoC, what would be the consequence of
>> enabling ATID? Would it simply be a no-op, or are there any side
>> effects? Or is the concern that the trace IDs could be exhausted?
>>
>
> TPDM0(or ATB source) -> interconnect TraceNoC0 -> Aggregator TraceNoc ->
> sink
> TPDM1(or ATB source) -> interconnect TraceNoC1 -> Aggregator TraceNoc ->
> sink
>
> We only have one Aggregator TraceNoC and many interconnect TraceNoC
> devices for one platform. All interconnect TraceNoC devices are
> connected to Aggregator TraceNoC devices in the topology, so the itnoc
> doesnt need an ATID.
>
> That's the design purpose from hardware perspective.
>
>
>> - How can you guarantee that a interconnect TraceNoC will never
>> require ATID in the future?
>>
>
> The interconnect TraceNoC is primarily introduced to reduce routing
> complexity in the hardware design. It is typically deployed as an
> intermediate TraceNoC that connects to an Aggregator TraceNoC (AG
> TraceNoC).
You can always distinguish one from the other by checking the
"compatibles" or even add a custom data field to the of_device_id
table for the platform driver. Personally, I think it is better to
keep things away from AMBA framework, when we get everything from
platform driver.
Cheers
Suzuki
>
> For example, a modem subsystem may contain many TPDM devices. Directly
> connecting every TPDM to the AG TraceNoC would result in significant
> wiring complexity. Instead, an itnoc is placed within the modem
> subsystem to locally aggregate the TPDM connections. All TPDMs first
> connect to the itnoc, and the itnoc then connects to the system-level AG
> TraceNoC.
>
> From a hardware perspective, there is no fundamental difference between
> an itnoc and an AG TraceNoC. They use the same TraceNoC hardware
> implementation and share the same AMBA bus type. The distinction is
> purely functional: an itnoc is used for local trace aggregation within a
> subsystem, whereas an AG TraceNoC serves as the top-level aggregation
> point for the SoC.
>
> Thanks,
> Jie
>
>>> The TraceNoC device here must be treated as an AMBA device and I am
>>> continuing to investigate the issue with our hardware team.
>>
>>> We aim to fix it from hardware perspetive for existing platforms if
>>> possible
>>> and ensure it is fixed in future platforms.
>>
>> I'm concerned that all of use end up repeatedly fixing similar issues
>> whenever hardware configurations change or modules are reused in
>> different topologies.
>>
>> For example, if future platforms may require ATID support for an
>> interconnect TraceNoC, then the issue will pop up again.
>>
>> Thanks,
>> Leo
>
^ permalink raw reply
* Re: [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Manikanta Maddireddy @ 2026-06-30 8:21 UTC (permalink / raw)
To: Manivannan Sadhasivam, Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
Aksh Garg, linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <23rcfdnhnjhdlhiw6eclxap2tk6j5ni7qkfsd3fkfmucvjemie@fvf4j5earp47>
On 30/06/26 1:33 pm, Manivannan Sadhasivam wrote:
>>>> +static void tegra264_pcie_remove(struct platform_device *pdev)
>>>> +{
>>>> + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
>>>> +
>>>> + /*
>>>> + * If we undo tegra264_pcie_init() then link goes down and need
>>>> + * controller reset to bring up the link again. Remove intention is
>>>> + * to clean up the root bridge and re-enumerate during bind.
>>> But the controller will be consuming power even if PCIe is not used. Do you
>>> really want that? Can't tegra264_pcie_init() handle the initialization? I'm
>>> wondering how tegra264_pcie_deinit() in tegra264_pcie_suspend() works then.
>> I had to clarify this with the PCI team and they indicated that
>> tegra264_pcie_deinit() is actually useless and maybe even harmful. The
>> reason is that there's a processor on these boards (BPMP) that takes
>> care of power sequencing and it will automatically take the PCI links
>> to L2 on suspend and assert PERST#.
>>
> Then why are you calling tegra264_pcie_deinit() in tegra264_pcie_suspend()? If
> tegra264_pcie_deinit() is harmful, then calling it during suspend should also
> be, right?
>
> Or tegra264_pcie_deinit() has to be paired with BPMP doing its own power
> sequencing?
>
> Not a big deal, but it just feels weird to see suspend() and remove() doing
> different things.
tegra264_pcie_deinit() should be removed in tegra264_pcie_suspend(),
BPMP-FW takes care of L2+assert PERST# sequence during suspend.
- Manikanta
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-30 8:10 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Konrad Dybcio,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Yuanfang Zhang, linux-arm-msm, devicetree, linux-kernel,
coresight, linux-arm-kernel
In-Reply-To: <adb45638-1787-45cd-b4fd-d957323cc608@oss.qualcomm.com>
Hi Jie,
On Tue, Jun 30, 2026 at 09:03:52AM +0800, Jie Gan wrote:
[...]
> > - How can you guarantee that a interconnect TraceNoC will never
> > require ATID in the future?
> From a hardware perspective, there is no fundamental difference between an
> itnoc and an AG TraceNoC. They use the same TraceNoC hardware implementation
> and share the same AMBA bus type. The distinction is purely functional: an
> itnoc is used for local trace aggregation within a subsystem, whereas an AG
> TraceNoC serves as the top-level aggregation point for the SoC.
I'm still not convinced that adding "arm,primecell-periphid" is the
right approach.
From the description above, I'd expect either the hardware to expose
bits in a register to distinguish these two module types, or as I
suggested earlier, to use a DT property to indicate the module type (or
whether ATID is required).
Or have you tried to detect the last tnoc on a path and allocate ID for
it? (You can retrieve csdev->path).
Thanks,
Leo
^ permalink raw reply
* RE: [PATCH v2 1/4] dt-bindings: connector: Add fsl,aud-io-slot binding
From: Chancel Liu (OSS) @ 2026-06-30 8:06 UTC (permalink / raw)
To: Rob Herring, Chancel Liu (OSS)
Cc: krzk+dt@kernel.org, conor+dt@kernel.org, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260629133253.GA2593312-robh@kernel.org>
> > From: Chancel Liu <chancel.liu@nxp.com>
> >
> > The NXP AUD-IO slot represents a physically present I/O connector on
> > the base board. It acts as a nexus that exposes a constrained set of
> > I/O resources, such as GPIOs, clocks and interrupts, through fixed
> > electrical wiring. All actual hardware providers reside on the base
> > board. The connector node only defines index-based mappings to those
> > providers.
> >
> > This connector type is present on i.MX95 19x19 EVK and i.MX952 EVK,
> > where it is used to attach the IMX-AUD-IO audio expansion card[1]. The
> > same add-on board can be reused across different base boards that
> > carry this connector.
> >
> > [1]https://www.nxp.com/part/IMX-AUD-IO
> >
> > Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> > ---
> > .../bindings/connector/fsl,aud-io-slot.yaml | 113 ++++++++++++++++++
> > 1 file changed, 113 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> > b/Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> > new file mode 100644
> > index 000000000000..5085574d221b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/connector/fsl,aud-io-slot.yaml
> > @@ -0,0 +1,113 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/connector/fsl,aud-io-slot.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP AUD-IO Slot
> > +
> > +maintainers:
> > + - Frank Li <Frank.li@nxp.com>
> > + - Chancel Liu <chancel.liu@nxp.com>
> > +
> > +description:
> > + The NXP AUD-IO slot represents a physically present I/O connector
> > +on
> > + the base board. It acts as a nexus that exposes a constrained set
> > +of
> > + I/O resources, such as GPIOs, clocks and interrupts, through fixed
> > + electrical wiring. All actual hardware providers reside on the base
> > + board. The connector node only defines index-based mappings to
> > +those
> > + providers. This connector type is present on i.MX95 19x19 EVK and
> > + i.MX952 EVK, where it is used to attach the IMX-AUD-IO expansion
> card.
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - fsl,imx952-evk-aud-io
> > + - const: fsl,imx95-19x19-evk-aud-io
> > + - const: fsl,imx95-19x19-evk-aud-io
> > +
> > + gpio-controller: true
> > +
> > + '#gpio-cells':
> > + const: 2
> > +
> > + gpio-map:
> > + minItems: 1
> > + maxItems: 32
>
> You don't know how many GPIOs are on the connector?
>
Understood. I used a loose upper bound here, which is wrong. I will
constrain gpio-map to the exact number of GPIOs on the connector.
> > +
> > + gpio-map-mask:
> > + items:
> > + - const: 0xffff
> > + - const: 0x0
> > +
> > + gpio-map-pass-thru:
> > + items:
> > + - const: 0x0
> > + - const: 0x1
> > +
> > + '#clock-cells':
> > + const: 1
> > +
> > + clock-map:
> > + minItems: 1
> > + maxItems: 16
>
> You don't know how many clocks are on the connector?
>
Same here.
> > +
> > + clock-map-mask:
> > + items:
> > + - const: 0xff
>
> > +
> > + clock-map-pass-thru: true
>
> The purpose of this property (for GPIO) was to pass thru flag cells which
> are standardized. That's not the case for clocks.
>
Agreed. I will drop clock-map-pass-thru.
> Anyways, these properties need to be defined in dtschema first.
>
> Rob
Yes. As noted in the cover letter, this series depends on Miquel
Raynal's clock nexus binding/core support:
https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/
This series is intended to be applied only after the clock nexus binding
and core support are available.
Regards,
Chancel Liu
^ permalink raw reply
* Re: [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Manivannan Sadhasivam @ 2026-06-30 8:03 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
Aksh Garg, linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <aju3jokcWR5DzPrv@orome>
On Wed, Jun 24, 2026 at 02:35:04PM +0200, Thierry Reding wrote:
[...]
> > So not hotplug support? Also, you do not want the driver to error out? I'm
> > wondering what's the use then?
>
> Hotplug is supported via pciehp. We skip probing the host bridge if no
> link was detected because there's simply nothing attached to the port,
> otherwise the link would've come up.
>
> pcie->link_up is slightly misleading because it actually means something
> along the lines of "link could be up at some point", either during probe
> or after some hotplug event later on. It is only ever false if there's
> no link during probe and hotplug isn't supported at all.
>
Ok. But if you skip pci_host_probe() then Root Port won't be enumerated at all.
I think that would give a false indication to the user. Typically, Root Port
would get enumerated during probe even if there are no devices atttached and
once the device gets attached, pciehp will enumerate the device.
> > > +
> > > + err = pci_host_probe(bridge);
> > > + if (err < 0) {
> > > + dev_err_probe(dev, err, "failed to register host\n");
> > > + goto free_ecam;
> > > + }
> > > +
> > > + return 0;
> > > +
> > > +free_ecam:
> >
> > Nit: Prefix 'err' for the labels.
>
> I don't see any benefit of adding a prefix. Seems pretty redundant, but
> I also don't feel too strongly about it, so I can add it.
>
People tend to use goto labels to do skip some steps also. So if the error
conditions are prefixed with 'err_' it helps to differentiate between them.
> > > + pci_ecam_free(pcie->cfg);
> > > +put_pm:
> > > + pm_runtime_put_sync(dev);
> > > +put_bpmp:
> > > + tegra_bpmp_put(pcie->bpmp);
> > > +
> > > + return err;
> > > +}
> > > +
> > > +static void tegra264_pcie_remove(struct platform_device *pdev)
> > > +{
> > > + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> > > +
> > > + /*
> > > + * If we undo tegra264_pcie_init() then link goes down and need
> > > + * controller reset to bring up the link again. Remove intention is
> > > + * to clean up the root bridge and re-enumerate during bind.
> >
> > But the controller will be consuming power even if PCIe is not used. Do you
> > really want that? Can't tegra264_pcie_init() handle the initialization? I'm
> > wondering how tegra264_pcie_deinit() in tegra264_pcie_suspend() works then.
>
> I had to clarify this with the PCI team and they indicated that
> tegra264_pcie_deinit() is actually useless and maybe even harmful. The
> reason is that there's a processor on these boards (BPMP) that takes
> care of power sequencing and it will automatically take the PCI links
> to L2 on suspend and assert PERST#.
>
Then why are you calling tegra264_pcie_deinit() in tegra264_pcie_suspend()? If
tegra264_pcie_deinit() is harmful, then calling it during suspend should also
be, right?
Or tegra264_pcie_deinit() has to be paired with BPMP doing its own power
sequencing?
Not a big deal, but it just feels weird to see suspend() and remove() doing
different things.
> Another reason why we don't want to reset the entire controller is that
> it is already set up during early boot by UEFI and the kernel driver
> does not redo the entire initialization.
>
So tegra264_pcie_init() is not the full initialization? If so, is it sufficient
during resume()?
> So yes, I think a little bit of power consumption is the compromise that
> we will have to live with. In the bigger picture it's probably not going
> to be noticeable in most cases, and given that these are embedded
> platforms we'll likely see fixed configurations most of the time and the
> case where we remove the PCIe host controller will not be common.
>
Fair enough.
> > > + */
> > > + pci_lock_rescan_remove();
> > > + pci_stop_root_bus(pcie->bridge->bus);
> > > + pci_remove_root_bus(pcie->bridge->bus);
> > > + pci_unlock_rescan_remove();
> > > +
> > > + pm_runtime_put_sync(&pdev->dev);
> > > + tegra_bpmp_put(pcie->bpmp);
> > > + pci_ecam_free(pcie->cfg);
> > > +}
> > > +
> > > +static int tegra264_pcie_suspend(struct device *dev)
> > > +{
> > > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > > + int err;
> > > +
> > > + tegra264_pcie_deinit(pcie);
> > > +
> > > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > > + err = enable_irq_wake(pcie->wake_irq);
> > > + if (err < 0)
> > > + dev_err(dev, "failed to enable wake IRQ: %pe\n",
> > > + ERR_PTR(err));
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int tegra264_pcie_resume(struct device *dev)
> > > +{
> > > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > > + int err;
> > > +
> > > + err = pinctrl_pm_select_default_state(dev);
> > > + if (err < 0)
> > > + dev_err(dev, "failed to configure sideband pins: %pe\n",
> > > + ERR_PTR(err));
> >
> > Please remind me if you justified this manual pinctrl handling before.
>
> This is just regular pinctrl PM boilerplate. There's plenty of other
> drivers where we do this, too. We want this because some of the pins
> get configured to non-default states on boot/resume, so doing this
> here ensures they are muxed correctly.
>
But pinctrl core should already be doing it for you, no?
> > > +
> > > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > > + err = disable_irq_wake(pcie->wake_irq);
> > > + if (err < 0)
> > > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > > + ERR_PTR(err));
> > > + }
> > > +
> > > + if (pcie->link_up == false)
> > > + return 0;
> >
> > How is this possible? If 'pcie->link_up' was 'false' during probe(), then it is
> > going to stay until tegra264_pcie_init() is called below.
>
> Yes, this keeps confusing me, too. The purpose of this is to skip
> initialization if we've already determined during probe that there is
> never going to be a link.
But you are calling tegra264_pcie_deinit() during tegra264_pcie_suspend()
unconditionally. So even if 'pcie->link_up' was false, the controller needs to
be initialized (atleast partially), right? Because, you are calling
tegra264_pcie_init() during probe() before 'pcie->link_up' check.
> link_up will be false if and only if there was
> no link during probe and we don't expect there ever will be a link
> because there is no hotplug support.
>
But above you said that this controller supports hotplug. Which one of the
statement is true?
> Maybe a different name for link_up could help here? maybe_link_up
> perhaps? I don't know if that's any clearer, but I also couldn't come up
> with a better name.
>
> Or maybe we should split this into two booleans, since we're essentially
> trying to use one boolean to track a tristate. What we want to know is
> if a link is truly up and if the controller should be kept powered for
> the case where hotplug is supported.
>
> I suppose we could do:
>
> bool link_up; /* track the link state */
> bool supports_hotplug; /* track whether port is hotpluggable */
>
Based on what criteria you'll set 'supports_hotplug' flag?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Songwei.Chai @ 2026-06-30 8:01 UTC (permalink / raw)
To: Suzuki K Poulose, Greg KH, Jie Gan
Cc: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
james.clark, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel,
linux-arm-msm, coresight, devicetree
In-Reply-To: <ce9a2121-8f7e-4ac2-8795-5ee602966e74@arm.com>
On 6/29/2026 6:44 PM, Suzuki K Poulose wrote:
> Hello,
>
> On 29/06/2026 11:17, Songwei.Chai wrote:
>>
>> On 6/29/2026 12:22 PM, Greg KH wrote:
>>> On Mon, Jun 29, 2026 at 11:03:33AM +0800, Songwei.Chai wrote:
>>>> Hi Greg & Alexander,
>>>>
>>>> Apologies for interrupting again.
>>>>
>>>> As the TGU hardware plays an important role in Qualcomm tracing
>>>> design, I
>>>> would greatly appreciate it if you could kindly take some time to
>>>> review
>>>> this at your earliest convenience.
>>> The merge window _just_ closed, please give us a chance to catch up.
>>>
>>> Also, why us? Surely you have other reviewers for this code, right?
>>
>> Hi Greg,
>>
>> Understood, thanks for letting us know.
>>
>> Regarding your question: since this introduces a new
>> drivers/hwtracing/ qcom directory, there is no existing maintainer
>> for it.
>> Given your scope (and Alexander's), we believe you are the most
>> relevant reviewers.
>>
>> The reason for creating the qcom directory is as follows:
>>
>> /We previously tried to upstream this driver under drivers/hwtracing/
>> coresight,/
>> /but it was not accepted as it is considered Qualcomm-specific and
>> not tightly/
>> /coupled with the CoreSight subsystem. Based on this feedback, we are
>
> Some clarification here: This device is not CoreSight so we denied
> keeping this under drivers/hwtracing/coresight/ - Not because it is
> Qualcomm specific. We have TPDM, TPDA, TnoC devices under the coresight
> subsystem, which are all Qualcomm specific for e.g.
>
> That said, there are other drivers in drivers/hwtracing/ which I usually
> merge and push to Greg, after some reviews/acks from the respective
> people (e.g., PTT HiSilicon PCIe Tune and Trace).
>
> But, your proposal was that there were other maintainers for your new
> subtree and you were going to push this via ,linux-arm-msm ? to which I
> didn't have any objections.
>
> That said, I am fine with pushing this to Greg via the CoreSight pull
> requests (similar to Hisilicon PTT driver), but would need someone to
> Maintain/Review the driver (with entries in MAINTAINERS, similar to
> PTT).
>
>
> Thoughts ?
Hi Suzuki,
Thank you for your constructive feedback in helping us move this patch
forward.
As the owner of this driver, together with Jie Gan (who has extensive
review experience), we will be responsible for the maintenance and
review going forward.
The MAINTAINERS update will be included in the next TGU release.
Feel free to share any additional comments.
Thanks,
Songwei
>
> Kind regards
> Suzuki
>
>
>
>> exploring/
>> /a dedicated drivers/hwtracing/qcom directory, similar to intel_th,
>> to better/
>> /support this and future Qualcomm hwtracing drivers./
>>
>> More details can be found in “[PATCH v14 0/7] -- Why we are proposing
>> this”.
>>
>> Thanks,
>> Songwei
>>
>>>
>>> thanks,
>>>
>>> greg k-h
>
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Bartosz Golaszewski @ 2026-06-30 7:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, 29 Jun 2026 15:26:20 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
>
> Arnd
Thanks for doing this Arnd!
For the series:
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH net-next 10/14] net: enetc: refactor SI VLAN promiscuous mode configuration
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Since a PCI FLR (Function Level Reset) is performed during probe, and
the hardware enables VLAN promiscuous mode for all SIs by default after
reset, there is no need to explicitly set it in enetc_configure_port().
Remove the redundant initialization of vlan_promisc_simap and the call
to enetc_set_vlan_promisc() from enetc_configure_port().
Remove the enetc_set_vlan_promisc(), enetc_enable_si_vlan_promisc() and
enetc_disable_si_vlan_promisc() functions, and introduce a new unified
function enetc_set_si_vlan_promisc() to enable or disable VLAN
promiscuous mode for a specific SI. This simplifies the logic and makes
the interface more straightforward.
As ENETC V4 only changes the address offset of PSIPVMR register compared
to V1 without any functional difference, enetc_set_si_vlan_promisc() can
be moved to enetc_pf_common.c in the future with minor adjustments to be
reused by the ENETC V4 driver
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
.../net/ethernet/freescale/enetc/enetc_hw.h | 5 ++-
.../net/ethernet/freescale/enetc/enetc_pf.c | 35 +++++++------------
.../net/ethernet/freescale/enetc/enetc_pf.h | 1 -
3 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 66bfda60da9c..16da732dc5de 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -185,9 +185,8 @@ enum enetc_bdr_type {TX, RX};
#define PSIPMMR_SI_MAC_MP(n) BIT((n) + 16)
#define ENETC_PSIPVMR 0x001c
-#define ENETC_VLAN_PROMISC_MAP_ALL 0x7
-#define ENETC_PSIPVMR_SET_VP(simap) ((simap) & 0x7)
-#define ENETC_PSIPVMR_SET_VUTA(simap) (((simap) & 0x7) << 16)
+#define PSIPVMR_SI_VLAN_P(n) BIT(n) /* n = SI index */
+
#define ENETC_PSIPMAR0(n) (0x0100 + (n) * 0x8) /* n = SI index */
#define ENETC_PSIPMAR1(n) (0x0104 + (n) * 0x8)
#define ENETC_PVCLCTR 0x0208
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index db2a800a7aaf..096ccb35508c 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -42,24 +42,20 @@ static void enetc_pf_destroy_pcs(struct phylink_pcs *pcs)
lynx_pcs_destroy(pcs);
}
-static void enetc_set_vlan_promisc(struct enetc_hw *hw, char si_map)
+static void enetc_set_si_vlan_promisc(struct enetc_si *si, int si_id,
+ bool promisc)
{
- u32 val = enetc_port_rd(hw, ENETC_PSIPVMR);
+ struct enetc_hw *hw = &si->hw;
+ u32 val;
- val &= ~ENETC_PSIPVMR_SET_VP(ENETC_VLAN_PROMISC_MAP_ALL);
- enetc_port_wr(hw, ENETC_PSIPVMR, ENETC_PSIPVMR_SET_VP(si_map) | val);
-}
+ val = enetc_port_rd(hw, ENETC_PSIPVMR);
-static void enetc_enable_si_vlan_promisc(struct enetc_pf *pf, int si_idx)
-{
- pf->vlan_promisc_simap |= BIT(si_idx);
- enetc_set_vlan_promisc(&pf->si->hw, pf->vlan_promisc_simap);
-}
+ if (promisc)
+ val |= PSIPVMR_SI_VLAN_P(si_id);
+ else
+ val &= ~PSIPVMR_SI_VLAN_P(si_id);
-static void enetc_disable_si_vlan_promisc(struct enetc_pf *pf, int si_idx)
-{
- pf->vlan_promisc_simap &= ~BIT(si_idx);
- enetc_set_vlan_promisc(&pf->si->hw, pf->vlan_promisc_simap);
+ enetc_port_wr(hw, ENETC_PSIPVMR, val);
}
static void enetc_set_isol_vlan(struct enetc_hw *hw, int si, u16 vlan, u8 qos)
@@ -442,10 +438,6 @@ static void enetc_configure_port(struct enetc_pf *pf)
/* split up RFS entries */
enetc_port_assign_rfs_entries(pf->si);
- /* enforce VLAN promisc mode for all SIs */
- pf->vlan_promisc_simap = ENETC_VLAN_PROMISC_MAP_ALL;
- enetc_set_vlan_promisc(hw, pf->vlan_promisc_simap);
-
enetc_port_wr(hw, ENETC_PSIPMMR, 0);
/* enable port */
@@ -466,12 +458,9 @@ static int enetc_pf_set_features(struct net_device *ndev,
}
if (changed & NETIF_F_HW_VLAN_CTAG_FILTER) {
- struct enetc_pf *pf = enetc_si_priv(priv->si);
+ bool promisc = !(features & NETIF_F_HW_VLAN_CTAG_FILTER);
- if (!!(features & NETIF_F_HW_VLAN_CTAG_FILTER))
- enetc_disable_si_vlan_promisc(pf, 0);
- else
- enetc_enable_si_vlan_promisc(pf, 0);
+ enetc_set_si_vlan_promisc(priv->si, 0, promisc);
}
if (changed & NETIF_F_LOOPBACK)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index 6f15f9ea1664..574ab4e76d8b 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -46,7 +46,6 @@ struct enetc_pf {
struct work_struct msg_task;
char msg_int_name[ENETC_INT_NAME_MAX];
- char vlan_promisc_simap; /* bitmap of SIs in VLAN promisc mode */
DECLARE_BITMAP(vlan_ht_filter, ENETC_VLAN_HT_SIZE);
DECLARE_BITMAP(active_vlans, VLAN_N_VID);
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 09/14] net: enetc: remove enetc4_set_default_si_vlan_promisc()
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
PF performs PCI FLR during driver probe, which resets the PSIPVMR
register to its default state where VLAN promiscuous mode is enabled
for all SIs.
The explicit call to enetc4_set_default_si_vlan_promisc() in probe
is therefore redundant. Remove it.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc4_pf.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
index 67aaf188d325..43883b55974a 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
@@ -310,17 +310,6 @@ static void enetc4_pf_set_si_vlan_promisc(struct enetc_hw *hw, int si, bool en)
enetc_port_wr(hw, ENETC4_PSIPVMR, val);
}
-static void enetc4_set_default_si_vlan_promisc(struct enetc_pf *pf)
-{
- struct enetc_hw *hw = &pf->si->hw;
- int num_si = pf->caps.num_vsi + 1;
- int i;
-
- /* enforce VLAN promiscuous mode for all SIs */
- for (i = 0; i < num_si; i++)
- enetc4_pf_set_si_vlan_promisc(hw, i, true);
-}
-
/* Allocate the number of MSI-X vectors for per SI. */
static void enetc4_set_si_msix_num(struct enetc_pf *pf)
{
@@ -364,8 +353,6 @@ static void enetc4_configure_port_si(struct enetc_pf *pf)
/* Outer VLAN tag will be used for VLAN filtering */
enetc_port_wr(hw, ENETC4_PSIVLANFMR, PSIVLANFMR_VS);
- enetc4_set_default_si_vlan_promisc(pf);
-
/* Disable SI MAC multicast & unicast promiscuous */
enetc_port_wr(hw, ENETC4_PSIPMMR, 0);
--
2.34.1
^ permalink raw reply related
* RE: [PATCH V2 0/2] PCI: imx6: Improve PERST# fallback logic
From: Sherry Sun @ 2026-06-30 7:50 UTC (permalink / raw)
To: Manivannan Sadhasivam, Manivannan Sadhasivam
Cc: Hongxing Zhu, l.stach@pengutronix.de, Frank Li,
bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, will@kernel.org,
Sherry Sun (OSS), imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <wj7dtqwadw4mletyq2s2an3g74acpmvvnkbogsdztgb27s2lul@i6ogmrnbd6to>
> Subject: Re: [PATCH V2 0/2] PCI: imx6: Improve PERST# fallback logic
>
> On Tue, Jun 30, 2026 at 09:20:12AM +0200, Manivannan Sadhasivam wrote:
> >
> > On Mon, 25 May 2026 14:54:41 +0800, Sherry Sun (OSS) wrote:
> > > From: Sherry Sun <sherry.sun@nxp.com>
> > >
> > > The pci_host_common_parse_port() shouldn't decide whether to fall
> > > back to the legacy RC-level binding by checking for "reset-gpios/reset-
> gpio"
> > > properties on the RC node and returning -ENODEV. That's a policy
> > > decision belongs to the caller, not this common helper.
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/2] PCI: host-generic: Simplify return value handling in
> pci_host_common_parse_port(s)
> > commit: 4b523544008aa70cda4b34c0589bbe47172c2637
> > [2/2] PCI: imx6: Add imx_pcie_perst_found() to inspect the parsed result
> > (no commit info)
> >
>
> I've squashed patch 2 with 1 to avoid bisectability issue pointed out by
> Sashiko and rewrote the subject/description as well.
>
Sure, thanks!
Best Regards
Sherry
^ permalink raw reply
* [PATCH net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Replace the open-coded struct_size() + kzalloc() pattern with the
kzalloc_flex() helper when allocating struct enetc_psfp_gate. This
removes the intermediate entries_size local variable and makes the
allocation site more concise.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc_qos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index 7b17bca24f26..2aa0fcaafcd2 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -1135,7 +1135,6 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
struct flow_action_entry *entry;
struct action_gate_entry *e;
u8 sfi_overwrite = 0;
- int entries_size;
int i, err;
if (f->common.chain_index >= priv->psfp_cap.max_streamid) {
@@ -1242,8 +1241,7 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
goto free_filter;
}
- entries_size = struct_size(sgi, entries, entryg->gate.num_entries);
- sgi = kzalloc(entries_size, GFP_KERNEL);
+ sgi = kzalloc_flex(*sgi, entries, entryg->gate.num_entries);
if (!sgi) {
err = -ENOMEM;
goto free_filter;
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
The VF driver uses alloc_etherdev_mq() with ENETC_MAX_NUM_TXQS as the
queue count, which forces the TX and RX queue counts to be equal and
uses a compile-time constant rather than the actual hardware capability.
After enetc_get_si_caps() is called, si->num_tx_rings and
si->num_rx_rings reflect the actual number of rings assigned to the VF
by the PF. Switch to alloc_etherdev_mqs() so that the TX and RX queue
counts are set independently based on the real hardware values, avoiding
unnecessary queue structure allocation when the VF has fewer rings than
ENETC_MAX_NUM_TXQS.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc_vf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
index 9cdb0a4d6baf..3df515a6e333 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
@@ -317,7 +317,8 @@ static int enetc_vf_probe(struct pci_dev *pdev,
enetc_get_si_caps(si);
- ndev = alloc_etherdev_mq(sizeof(*priv), ENETC_MAX_NUM_TXQS);
+ ndev = alloc_etherdev_mqs(sizeof(*priv), si->num_tx_rings,
+ si->num_rx_rings);
if (!ndev) {
err = -ENOMEM;
dev_err(&pdev->dev, "netdev creation failed\n");
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 08/14] net: enetc: remove invalid code from enetc4_pl_mac_link_up()
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
When adding phylink MAC operations support to the NETC switch driver,
Russell King pointed out several pieces of invalid logic in the
.mac_link_up() implementation (see [1] and [2]):
1) Half-duplex backpressure is not supported by the kernel, Ethernet
relies on packet dropping for congestion management.
2) phylink_autoneg_inband() is unnecessary, as RGMII in-band status is
not supported.
3) TX and RX pause are disabled in half-duplex mode, so there is no
need to override them in .mac_link_up().
The same invalid logic is also present in enetc4_pl_mac_link_up(), so
remove the invalid code from it.
Link: https://lore.kernel.org/imx/acEIQqI-_oyCym8O@shell.armlinux.org.uk/ # 1
Link: https://lore.kernel.org/imx/acEFwqmAvWls_9Ef@shell.armlinux.org.uk/ # 2
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
.../net/ethernet/freescale/enetc/enetc4_hw.h | 1 -
.../net/ethernet/freescale/enetc/enetc4_pf.c | 35 +------------------
2 files changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
index dea1fd0b8175..7a3ccc94b036 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
@@ -198,7 +198,6 @@
#define PM_CMD_CFG_CNT_FRM_EN BIT(13)
#define PM_CMD_CFG_TXP BIT(15)
#define PM_CMD_CFG_SEND_IDLE BIT(16)
-#define PM_CMD_CFG_HD_FCEN BIT(18)
#define PM_CMD_CFG_SFD BIT(21)
#define PM_CMD_CFG_TX_FLUSH BIT(22)
#define PM_CMD_CFG_TX_LOWP_EN BIT(23)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
index b21ff362c31e..67aaf188d325 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
@@ -588,11 +588,6 @@ static void enetc4_mac_config(struct enetc_pf *pf, unsigned int mode,
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
val |= IFMODE_RGMII;
- /* We need to enable auto-negotiation for the MAC
- * if its RGMII interface support In-Band status.
- */
- if (phylink_autoneg_inband(mode))
- val |= PM_IF_MODE_ENA;
break;
case PHY_INTERFACE_MODE_RMII:
val |= IFMODE_RMII;
@@ -690,22 +685,6 @@ static void enetc4_set_rmii_mac(struct enetc_pf *pf, int speed, int duplex)
enetc_port_mac_wr(si, ENETC4_PM_IF_MODE(0), val);
}
-static void enetc4_set_hd_flow_control(struct enetc_pf *pf, bool enable)
-{
- struct enetc_si *si = pf->si;
- u32 old_val, val;
-
- if (!pf->caps.half_duplex)
- return;
-
- old_val = enetc_port_mac_rd(si, ENETC4_PM_CMD_CFG(0));
- val = u32_replace_bits(old_val, enable ? 1 : 0, PM_CMD_CFG_HD_FCEN);
- if (val == old_val)
- return;
-
- enetc_port_mac_wr(si, ENETC4_PM_CMD_CFG(0), val);
-}
-
static void enetc4_set_rx_pause(struct enetc_pf *pf, bool rx_pause)
{
struct enetc_si *si = pf->si;
@@ -881,13 +860,11 @@ static void enetc4_pl_mac_link_up(struct phylink_config *config,
struct enetc_pf *pf = phylink_to_enetc_pf(config);
struct enetc_si *si = pf->si;
struct enetc_ndev_priv *priv;
- bool hd_fc = false;
priv = netdev_priv(si->ndev);
enetc4_set_port_speed(priv, speed);
- if (!phylink_autoneg_inband(mode) &&
- phy_interface_mode_is_rgmii(interface))
+ if (phy_interface_mode_is_rgmii(interface))
enetc4_set_rgmii_mac(pf, speed, duplex);
if (interface == PHY_INTERFACE_MODE_RMII)
@@ -899,18 +876,8 @@ static void enetc4_pl_mac_link_up(struct phylink_config *config,
*/
if (priv->active_offloads & ENETC_F_QBU)
tx_pause = false;
- } else { /* DUPLEX_HALF */
- if (tx_pause || rx_pause)
- hd_fc = true;
-
- /* As per 802.3 annex 31B, PAUSE frames are only supported
- * when the link is configured for full duplex operation.
- */
- tx_pause = false;
- rx_pause = false;
}
- enetc4_set_hd_flow_control(pf, hd_fc);
enetc4_set_tx_pause(pf, priv->num_rx_rings, tx_pause);
enetc4_set_rx_pause(pf, rx_pause);
enetc4_mac_tx_enable(pf);
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
The num_vsi field in struct enetc_port_caps is populated by reading the
NUM_VSI field of the ECAPR1 register, which reports the number of VSIs
supported by the ENETC4 port. This value is equivalent to the total
number of VFs reported by the PCI SR-IOV capability, which is already
stored in pf->total_vfs during probe via pci_sriov_get_totalvfs().
Since pf->total_vfs carries the same information and is already
available throughout the driver, there is no need to read and cache
num_vsi separately in the port capabilities structure. Remove the
num_vsi field from enetc_port_caps and the associated ECAPR1_NUM_VSI
macro, and replace all uses of pf->caps.num_vsi with pf->total_vfs in
the ring allocation, MSI-X configuration, SI enable, and debugfs code
paths.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
.../ethernet/freescale/enetc/enetc4_debugfs.c | 13 +++----
.../net/ethernet/freescale/enetc/enetc4_hw.h | 1 -
.../net/ethernet/freescale/enetc/enetc4_pf.c | 37 +++++++++----------
.../net/ethernet/freescale/enetc/enetc_pf.h | 1 -
4 files changed, 23 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
index be378bf8f74d..5029038bf99f 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
@@ -28,17 +28,14 @@ static void enetc_show_si_mac_hash_filter(struct seq_file *s, int i)
static int enetc_mac_filter_show(struct seq_file *s, void *data)
{
- struct enetc_si *si = s->private;
- struct enetc_hw *hw = &si->hw;
+ struct enetc_pf *pf = enetc_si_priv(s->private);
+ struct enetc_hw *hw = &pf->si->hw;
+ int num_si = pf->total_vfs + 1;
struct maft_entry_data maft;
struct ntmp_user *user;
- struct enetc_pf *pf;
u32 val, entry_id;
- int i, num_si;
int err = 0;
-
- pf = enetc_si_priv(si);
- num_si = pf->caps.num_vsi + 1;
+ int i;
val = enetc_port_rd(hw, ENETC4_PSIPMMR);
for (i = 0; i < num_si; i++) {
@@ -52,7 +49,7 @@ static int enetc_mac_filter_show(struct seq_file *s, void *data)
for (i = 0; i < num_si; i++)
enetc_show_si_mac_hash_filter(s, i);
- user = &si->ntmp_user;
+ user = &pf->si->ntmp_user;
rtnl_lock();
if (bitmap_empty(user->maft_eid_bitmap, user->maft_num_entries))
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
index 7a3ccc94b036..72b54fe02e65 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
@@ -50,7 +50,6 @@
#define ECAPR1_NUM_MCH GENMASK(9, 8)
#define ECAPR1_NUM_UCH GENMASK(11, 10)
#define ECAPR1_NUM_MSIX GENMASK(22, 12)
-#define ECAPR1_NUM_VSI GENMASK(27, 24)
#define ECAPR1_NUM_IPV BIT(31)
#define ENETC4_ECAPR2 0x8
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
index 52f84b5b838e..b4b8d3f08ab8 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
@@ -23,7 +23,6 @@ static void enetc4_get_port_caps(struct enetc_pf *pf)
u32 val;
val = enetc_port_rd(hw, ENETC4_ECAPR1);
- pf->caps.num_vsi = (val & ECAPR1_NUM_VSI) >> 24;
pf->caps.num_msix = ((val & ECAPR1_NUM_MSIX) >> 12) + 1;
val = enetc_port_rd(hw, ENETC4_ECAPR2);
@@ -258,34 +257,35 @@ static void enetc4_default_rings_allocation(struct enetc_pf *pf)
{
struct enetc_hw *hw = &pf->si->hw;
u32 num_rx_bdr, num_tx_bdr, val;
+ int num_vfs = pf->total_vfs;
u32 vf_tx_bdr, vf_rx_bdr;
int i, rx_rem, tx_rem;
- if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + pf->caps.num_vsi)
- num_rx_bdr = pf->caps.num_rx_bdr - pf->caps.num_vsi;
+ if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
+ num_rx_bdr = pf->caps.num_rx_bdr - num_vfs;
else
num_rx_bdr = ENETC_SI_MAX_RING_NUM;
- if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + pf->caps.num_vsi)
- num_tx_bdr = pf->caps.num_tx_bdr - pf->caps.num_vsi;
+ if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
+ num_tx_bdr = pf->caps.num_tx_bdr - num_vfs;
else
num_tx_bdr = ENETC_SI_MAX_RING_NUM;
val = enetc4_psicfgr0_val_construct(false, num_tx_bdr, num_rx_bdr);
enetc_port_wr(hw, ENETC4_PSICFGR0(0), val);
- if (!pf->caps.num_vsi)
+ if (!num_vfs)
return;
num_rx_bdr = pf->caps.num_rx_bdr - num_rx_bdr;
- rx_rem = num_rx_bdr % pf->caps.num_vsi;
- num_rx_bdr = num_rx_bdr / pf->caps.num_vsi;
+ rx_rem = num_rx_bdr % num_vfs;
+ num_rx_bdr = num_rx_bdr / num_vfs;
num_tx_bdr = pf->caps.num_tx_bdr - num_tx_bdr;
- tx_rem = num_tx_bdr % pf->caps.num_vsi;
- num_tx_bdr = num_tx_bdr / pf->caps.num_vsi;
+ tx_rem = num_tx_bdr % num_vfs;
+ num_tx_bdr = num_tx_bdr / num_vfs;
- for (i = 0; i < pf->caps.num_vsi; i++) {
+ for (i = 0; i < num_vfs; i++) {
vf_tx_bdr = (i < tx_rem) ? num_tx_bdr + 1 : num_tx_bdr;
vf_rx_bdr = (i < rx_rem) ? num_rx_bdr + 1 : num_rx_bdr;
val = enetc4_psicfgr0_val_construct(true, vf_tx_bdr, vf_rx_bdr);
@@ -302,26 +302,25 @@ static void enetc4_allocate_si_rings(struct enetc_pf *pf)
static void enetc4_set_si_msix_num(struct enetc_pf *pf)
{
struct enetc_hw *hw = &pf->si->hw;
- int i, num_msix, total_si;
+ int num_si = pf->total_vfs + 1;
+ int i, num_msix;
u32 val;
- total_si = pf->caps.num_vsi + 1;
-
- num_msix = pf->caps.num_msix / total_si +
- pf->caps.num_msix % total_si - 1;
+ num_msix = pf->caps.num_msix / num_si +
+ pf->caps.num_msix % num_si - 1;
val = num_msix & PSICFGR2_NUM_MSIX;
enetc_port_wr(hw, ENETC4_PSICFGR2(0), val);
- num_msix = pf->caps.num_msix / total_si - 1;
+ num_msix = pf->caps.num_msix / num_si - 1;
val = num_msix & PSICFGR2_NUM_MSIX;
- for (i = 0; i < pf->caps.num_vsi; i++)
+ for (i = 0; i < pf->total_vfs; i++)
enetc_port_wr(hw, ENETC4_PSICFGR2(i + 1), val);
}
static void enetc4_enable_all_si(struct enetc_pf *pf)
{
struct enetc_hw *hw = &pf->si->hw;
- int num_si = pf->caps.num_vsi + 1;
+ int num_si = pf->total_vfs + 1;
u32 si_bitmap = 0;
int i;
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index 574ab4e76d8b..9c36ba50a7f0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -18,7 +18,6 @@ struct enetc_vf_state {
struct enetc_port_caps {
u32 half_duplex:1;
- int num_vsi;
int num_msix;
int num_rx_bdr;
int num_tx_bdr;
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 11/14] net: enetc: move enetc_set_si_vlan_promisc() to enetc_pf_common.c
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
The PSIPVMR in ENETC v4 has the same bit layout and functionality as the
PSIPVMR register in ENETC v1: bit n (n <= 15) controls VLAN promiscuous
mode for SI n. The only difference between the two hardware generations
is the register address offset.
Since the register functionality is identical, the VLAN promiscuous mode
setting code can be shared between ENETC v1 and v4 drivers.
Move enetc_set_si_vlan_promisc() from enetc_pf.c to enetc_pf_common.c
and export it so that it can be shared between the two drivers. Add a
revision check using is_enetc_rev1() to select the correct register
offset (ENETC_PSIPVMR for v1 and ENETC4_PSIPVMR for v4) while keeping
the same logic.
Remove the v4-specific enetc4_pf_set_si_vlan_promisc() from enetc4_pf.c
and replace its call site with the new common enetc_set_si_vlan_promisc()
to eliminate code duplication.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
.../net/ethernet/freescale/enetc/enetc4_pf.c | 15 +------------
.../net/ethernet/freescale/enetc/enetc_pf.c | 16 --------------
.../freescale/enetc/enetc_pf_common.c | 22 +++++++++++++++++++
.../freescale/enetc/enetc_pf_common.h | 1 +
4 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
index 43883b55974a..52f84b5b838e 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
@@ -298,18 +298,6 @@ static void enetc4_allocate_si_rings(struct enetc_pf *pf)
enetc4_default_rings_allocation(pf);
}
-static void enetc4_pf_set_si_vlan_promisc(struct enetc_hw *hw, int si, bool en)
-{
- u32 val = enetc_port_rd(hw, ENETC4_PSIPVMR);
-
- if (en)
- val |= BIT(si);
- else
- val &= ~BIT(si);
-
- enetc_port_wr(hw, ENETC4_PSIPVMR, val);
-}
-
/* Allocate the number of MSI-X vectors for per SI. */
static void enetc4_set_si_msix_num(struct enetc_pf *pf)
{
@@ -517,12 +505,11 @@ static int enetc4_pf_set_features(struct net_device *ndev,
{
netdev_features_t changed = ndev->features ^ features;
struct enetc_ndev_priv *priv = netdev_priv(ndev);
- struct enetc_hw *hw = &priv->si->hw;
if (changed & NETIF_F_HW_VLAN_CTAG_FILTER) {
bool promisc_en = !(features & NETIF_F_HW_VLAN_CTAG_FILTER);
- enetc4_pf_set_si_vlan_promisc(hw, 0, promisc_en);
+ enetc_set_si_vlan_promisc(priv->si, 0, promisc_en);
}
if (changed & NETIF_F_LOOPBACK)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 096ccb35508c..ac282d17c0d3 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -42,22 +42,6 @@ static void enetc_pf_destroy_pcs(struct phylink_pcs *pcs)
lynx_pcs_destroy(pcs);
}
-static void enetc_set_si_vlan_promisc(struct enetc_si *si, int si_id,
- bool promisc)
-{
- struct enetc_hw *hw = &si->hw;
- u32 val;
-
- val = enetc_port_rd(hw, ENETC_PSIPVMR);
-
- if (promisc)
- val |= PSIPVMR_SI_VLAN_P(si_id);
- else
- val &= ~PSIPVMR_SI_VLAN_P(si_id);
-
- enetc_port_wr(hw, ENETC_PSIPVMR, val);
-}
-
static void enetc_set_isol_vlan(struct enetc_hw *hw, int si, u16 vlan, u8 qos)
{
u32 val = 0;
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
index adf79a99a8c8..cbcf43bac826 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
@@ -171,6 +171,28 @@ void enetc_set_si_mc_hash_filter(struct enetc_si *si, int si_id, u64 hash)
}
EXPORT_SYMBOL_GPL(enetc_set_si_mc_hash_filter);
+void enetc_set_si_vlan_promisc(struct enetc_si *si, int si_id, bool promisc)
+{
+ struct enetc_hw *hw = &si->hw;
+ int psipvmr_off;
+ u32 val;
+
+ if (is_enetc_rev1(si))
+ psipvmr_off = ENETC_PSIPVMR;
+ else
+ psipvmr_off = ENETC4_PSIPVMR;
+
+ val = enetc_port_rd(hw, psipvmr_off);
+
+ if (promisc)
+ val |= PSIPVMR_SI_VLAN_P(si_id);
+ else
+ val &= ~PSIPVMR_SI_VLAN_P(si_id);
+
+ enetc_port_wr(hw, psipvmr_off, val);
+}
+EXPORT_SYMBOL_GPL(enetc_set_si_vlan_promisc);
+
void enetc_pf_netdev_setup(struct enetc_si *si, struct net_device *ndev,
const struct net_device_ops *ndev_ops)
{
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.h b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.h
index bf9029b0a017..8243ce0de57f 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.h
@@ -21,6 +21,7 @@ void enetc_set_si_uc_promisc(struct enetc_si *si, int si_id, bool promisc);
void enetc_set_si_mc_promisc(struct enetc_si *si, int si_id, bool promisc);
void enetc_set_si_uc_hash_filter(struct enetc_si *si, int si_id, u64 hash);
void enetc_set_si_mc_hash_filter(struct enetc_si *si, int si_id, u64 hash);
+void enetc_set_si_vlan_promisc(struct enetc_si *si, int si_id, bool promisc);
static inline u16 enetc_get_ip_revision(struct enetc_hw *hw)
{
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Claudiu Manoil <claudiu.manoil@nxp.com>
The ENETC pseudo-MACs are proprietary internal links that do not
implement any standard MII interface, so restrict their supported PHY
interface modes to PHY_INTERFACE_MODE_INTERNAL only.
Since pseudo-MACs can operate at any speed between 10Mbps and 25Gbps
in multiples of 10Mbps, set their MAC capabilities to cover the full
range of standard full-duplex speeds: 10/100/1000/2500/5000/10000/
20000/25000 Mbps.
For standalone ENETC, expand the supported interface modes to include
10GBASER and XGMII in addition to the existing RGMII, SGMII, 1000BASEX,
2500BASEX and USXGMII modes, with MAC capabilities up to 10G. MAC_1000
is replaced with MAC_1000FD to explicitly exclude 1000M half-duplex,
which is not supported.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc.h | 2 +-
.../freescale/enetc/enetc_pf_common.c | 39 +++++++++++++------
2 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h
index 06a9f1ee0970..8839cfb49bcf 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
-/* Copyright 2017-2019 NXP */
+/* Copyright 2017-2019, 2025-2026 NXP */
#include <linux/timer.h>
#include <linux/pci.h>
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
index 3597cb81a7cc..adf79a99a8c8 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
-/* Copyright 2024 NXP */
+/* Copyright 2024-2026 NXP */
#include <linux/fsl/enetc_mdio.h>
#include <linux/of_mdio.h>
@@ -400,25 +400,40 @@ int enetc_phylink_create(struct enetc_ndev_priv *priv, struct device_node *node,
{
struct enetc_pf *pf = enetc_si_priv(priv->si);
struct phylink *phylink;
+ unsigned long mac_caps;
int err;
pf->phylink_config.dev = &priv->ndev->dev;
pf->phylink_config.type = PHYLINK_NETDEV;
- pf->phylink_config.mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
- MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD;
__set_bit(PHY_INTERFACE_MODE_INTERNAL,
pf->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_SGMII,
- pf->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_1000BASEX,
- pf->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_2500BASEX,
- pf->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_USXGMII,
- pf->phylink_config.supported_interfaces);
- phy_interface_set_rgmii(pf->phylink_config.supported_interfaces);
+ mac_caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE;
+ if (!enetc_is_pseudo_mac(priv->si)) {
+ mac_caps |= MAC_10 | MAC_100 | MAC_1000FD | MAC_2500FD |
+ MAC_5000FD | MAC_10000FD;
+
+ __set_bit(PHY_INTERFACE_MODE_SGMII,
+ pf->phylink_config.supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_1000BASEX,
+ pf->phylink_config.supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_2500BASEX,
+ pf->phylink_config.supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_USXGMII,
+ pf->phylink_config.supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_10GBASER,
+ pf->phylink_config.supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_XGMII,
+ pf->phylink_config.supported_interfaces);
+ phy_interface_set_rgmii(pf->phylink_config.supported_interfaces);
+ } else {
+ mac_caps |= MAC_10FD | MAC_100FD | MAC_1000FD | MAC_2500FD |
+ MAC_5000FD | MAC_10000FD | MAC_20000FD |
+ MAC_25000FD;
+ }
+
+ pf->phylink_config.mac_capabilities = mac_caps;
phylink = phylink_create(&pf->phylink_config, of_fwnode_handle(node),
pf->if_mode, ops);
if (IS_ERR(phylink)) {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 10/10] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun Chen @ 2026-06-30 7:47 UTC (permalink / raw)
To: chenhuacai, kernel, pjw, palmer, aou, robh, saravanak, bhe, rppt,
linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing
Cc: catalin.marinas, will, alex, akpm, pasha.tatashin, pratyush,
ruirui.yang, m.szyprowski, robin.murphy
In-Reply-To: <20260630074715.4126796-1-chenwandun1@gmail.com>
From: Wandun Chen <chenwandun@lixiang.com>
Apply the same non-dumpable reserved memory filtering to LoongArch
kdump as was done for arm64. Use of_reserved_mem_kdump_exclude() to
drop flagged regions from the elfcorehdr PT_LOAD segments, and
of_reserved_mem_kdump_nr_ranges() to pre-size the crash_mem array.
Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 5584b798ba46..4b918c3d4a28 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#include <linux/kexec.h>
#include <linux/memblock.h>
+#include <linux/of_reserved_mem.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/types.h>
@@ -67,6 +68,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
nr_ranges = 2; /* for exclusion of crashkernel region */
for_each_mem_range(i, &start, &end)
nr_ranges++;
+ nr_ranges += of_reserved_mem_kdump_nr_ranges();
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
if (!cmem)
@@ -91,6 +93,10 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
goto out;
}
+ ret = of_reserved_mem_kdump_exclude(cmem);
+ if (ret)
+ goto out;
+
ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 06/14] net: enetc: simplify enetc4_set_port_speed()
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Since phylink only passes valid speed values to mac_link_up, the switch
statement with its default fallback to SPEED_10 is unnecessary. Replace
it with a direct call to PCR_PSPEED_VAL(). Also update PCR_PSPEED_VAL()
to use FIELD_PREP() for proper field masking instead of an open-coded
shift.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
.../net/ethernet/freescale/enetc/enetc4_hw.h | 2 +-
.../net/ethernet/freescale/enetc/enetc4_pf.c | 19 +++----------------
2 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
index 6a8f2ed56017..dea1fd0b8175 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
@@ -148,7 +148,7 @@
#define PCR_L2DOSE BIT(4)
#define PCR_TIMER_CS BIT(8)
#define PCR_PSPEED GENMASK(29, 16)
-#define PCR_PSPEED_VAL(speed) (((speed) / 10 - 1) << 16)
+#define PCR_PSPEED_VAL(s) FIELD_PREP(PCR_PSPEED, ((s) / 10 - 1))
/* Port MAC address register 0/1 */
#define ENETC4_PMAR0 0x4020
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
index 4143438ea7a7..b21ff362c31e 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
@@ -631,23 +631,10 @@ static void enetc4_set_port_speed(struct enetc_ndev_priv *priv, int speed)
if (speed == old_speed)
return;
- val = enetc_port_rd(&priv->si->hw, ENETC4_PCR);
- val &= ~PCR_PSPEED;
-
- switch (speed) {
- case SPEED_100:
- case SPEED_1000:
- case SPEED_2500:
- case SPEED_10000:
- val |= (PCR_PSPEED & PCR_PSPEED_VAL(speed));
- break;
- case SPEED_10:
- default:
- val |= (PCR_PSPEED & PCR_PSPEED_VAL(SPEED_10));
- }
-
- priv->speed = speed;
+ val = enetc_port_rd(&priv->si->hw, ENETC4_PCR) & (~PCR_PSPEED);
+ val |= PCR_PSPEED_VAL(speed);
enetc_port_wr(&priv->si->hw, ENETC4_PCR, val);
+ priv->speed = speed;
}
static void enetc4_set_rgmii_mac(struct enetc_pf *pf, int speed, int duplex)
--
2.34.1
^ permalink raw reply related
* [PATCH net-next 05/14] net: enetc: use PCI device name for debugfs directory
From: wei.fang @ 2026-06-30 7:20 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260630072036.382761-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
enetc_create_debugfs() is called right after register_netdev(), at which
point ndev->name still holds the format template "eth%d" rather than the
final assigned name (e.g., via udev rules).
Use pci_name() instead of netdev_name() to name the debugfs directory.
The PCI device name is unique, stable, and available from the start,
making it a more reliable identifier for the debugfs entry.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
index 4a769d9e5679..be378bf8f74d 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
@@ -81,10 +81,9 @@ DEFINE_SHOW_ATTRIBUTE(enetc_mac_filter);
void enetc_create_debugfs(struct enetc_si *si)
{
- struct net_device *ndev = si->ndev;
struct dentry *root;
- root = debugfs_create_dir(netdev_name(ndev), NULL);
+ root = debugfs_create_dir(pci_name(si->pdev), NULL);
if (IS_ERR(root))
return;
--
2.34.1
^ 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