It is clear that due to the sequential nature of code execution, when
n_ops (initially zero) is incremented, attr_ops is also assigned from
the value of "attr" (the current iterator).
But some compilers, like gcc version 12.2.0 (Debian 12.2.0-14+deb12u1)
as distributed by Debian Bookworm, seem to be not sophisticated enough
to see this, and fail to compile (warnings treated as errors):
In file included from ../lib/ynl.h:10,
from nlctrl-user.c:9:
In function ‘ynl_attr_data_end’,
inlined from ‘nlctrl_getfamily_rsp_parse’ at nlctrl-user.c:427:3:
../lib/ynl-priv.h:209:44: warning: ‘attr_ops’ may be used uninitialized [-Wmaybe-uninitialized]
209 | return (char *)ynl_attr_data(attr) + ynl_attr_data_len(attr);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
nlctrl-user.c: In function ‘nlctrl_getfamily_rsp_parse’:
nlctrl-user.c:341:30: note: ‘attr_ops’ was declared here
341 | const struct nlattr *attr_ops;
| ^~~~~~~~
It is a pity that we have to do this, but I see no other way than to
suppress the false positive by appeasing the compiler and initializing
the "*attr_{aspec.c_name}" variable with a bogus value (NULL). This will
never be used - at runtime it will always be overwritten when
"n_{struct[anest].c_name}" is non-zero.
====================
Add Ethernet MAC support for SpacemiT K1
SpacemiT K1 has two gigabit Ethernet MACs with RGMII and RMII support.
Add devicetree bindings, driver, and DTS for it.
Tested primarily on BananaPi BPI-F3. Basic TX/RX functionality also
tested on Milk-V Jupiter.
I would like to note that even though some bit field names superficially
resemble that of DesignWare MAC, all other differences point to it in
fact being a custom design.
Based on SpacemiT drivers [1]. These patches are also available at:
Vivian Wang [Sun, 14 Sep 2025 04:23:15 +0000 (12:23 +0800)]
riscv: dts: spacemit: Add Ethernet support for BPI-F3
Banana Pi BPI-F3 uses an RGMII PHY for each port and uses GPIO for PHY
reset.
Tested-by: Hendrik Hamerlinck <hendrik.hamerlinck@hammernet.be> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Yixun Lan <dlan@gentoo.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250914-net-k1-emac-v12-4-65b31b398f44@iscas.ac.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Vivian Wang [Sun, 14 Sep 2025 04:23:13 +0000 (12:23 +0800)]
net: spacemit: Add K1 Ethernet MAC
The Ethernet MACs found on SpacemiT K1 appears to be a custom design
that only superficially resembles some other embedded MACs. SpacemiT
refers to them as "EMAC", so let's just call the driver "k1_emac".
Supports RGMII and RMII interfaces. Includes support for MAC hardware
statistics counters. PTP support is not implemented.
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Tested-by: Junhui Liu <junhui.liu@pigmoral.tech> Tested-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Link: https://patch.msgid.link/20250914-net-k1-emac-v12-2-65b31b398f44@iscas.ac.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
====================
net: hinic3: Add a driver for Huawei 3rd gen NIC - sw and hw initialization
This is [3/3] part of hinic3 Ethernet driver initial submission.
With this patch hinic3 becomes a functional Ethernet driver.
The driver parts contained in this patch:
Memory allocation and initialization of the driver structures.
Management interfaces initialization.
HW capabilities probing, initialization and setup using management
interfaces.
Net device open/stop implementation and data queues initialization.
Register VID:DID in PCI id_table.
Fix netif_queue_set_napi usage.
Fan Gong [Fri, 12 Sep 2025 06:28:30 +0000 (14:28 +0800)]
hinic3: Fix missing napi->dev in netif_queue_set_napi
As netif_queue_set_napi checks napi->dev, if it doesn't have it and
it will warn_on and return. So we should use netif_napi_add before
netif_queue_set_napi because netif_napi_add has "napi->dev = dev".
Fix a -Wmaybe-uninitialized warning by initializing the variable to
NULL. The warning is bogus and should not happen, but fixing it allows
running the check on the driver to catch potential future problems.
$ make CFLAGS_ravb_main.o=-Wmaybe-uninitialized
In function 'ravb_rx_csum_gbeth',
inlined from 'ravb_rx_gbeth' at .../linux/drivers/net/ethernet/renesas/ravb_main.c:923:6:
.../linux/drivers/net/ethernet/renesas/ravb_main.c:765:25: error: 'skb' may be used uninitialized [-Werror=maybe-uninitialized]
765 | if (unlikely(skb->len < csum_len))
| ~~~^~~~~
.../linux/include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
.../linux/drivers/net/ethernet/renesas/ravb_main.c: In function 'ravb_rx_gbeth':
.../linux/drivers/net/ethernet/renesas/ravb_main.c:806:25: note: 'skb' was declared here
806 | struct sk_buff *skb;
| ^~~
cc1: all warnings being treated as errors
Warning was found when cross compiling using aarch64-linux-gnu-gcc (GCC)
15.1.0.
Stefan Wahren [Fri, 12 Sep 2025 14:03:32 +0000 (16:03 +0200)]
ethernet: Extend device_get_mac_address() to use NVMEM
A lot of modern SoC have the ability to store MAC addresses in their
NVMEM. So extend the generic function device_get_mac_address() to
obtain the MAC address from an nvmem cell named 'mac-address' in
case there is no firmware node which contains the MAC address directly.
Some attribute-set have a documentation (doc:), but they are not
displayed in the RST / HTML version. This series adds the missing
parsing of these 'doc' fields.
While at it, it also fixes how the 'doc' fields are declared on multiple
lines.
====================
In YAML, it is allowed to declare a scalar strings at the next lines
without explicitly declaring them as a block. Yet, they looks weird, and
can cause issues when ':' or '#' are present.
The modified lines didn't have issues with the special characters, but
it seems better to explicitly declare such blocks as scalar strings to
encourage people to "properly" declare future scalar strings.
The right angle bracket is used with a minus sign to indicate that the
folded style should be used without adding extra newlines. By doing
that, the output is not changed compared to what was done before this
patch.
By default, strings defined in YAML at the next line are folded:
newlines are replaced by spaces. Here, the newlines are there for a
reason, and should be kept in the output.
This can be fixed by adding the '|' symbol to use the "literal" style.
This issue was introduced by commit 387724cbf415 ("Documentation:
netlink: add a YAML spec for team"), but visible in the doc only since
the parent commit.
To avoid warnings when generating the HTML output, and to look better,
the code layout is now in a dedicated code block, which requires '::'
and a new blank line. Just for a question of uniformity, a new blank
line is also added after the code block.
Some attribute-set have a documentation (doc:), but it was not displayed
in the RST / HTML version. Such field can be found in ethtool, netdev,
tcp_metrics and team YAML files.
Only the 'name' and 'attributes' fields from an 'attribute-set' section
were parsed. Now the content of the 'doc' field, if available, is added
as a new paragraph before listing each attribute. This is similar to
what is done when parsing the 'operations'.
ASPM isn't disabled if system vendor flags it as safe. Log this,
in order to know whom to blame if a user complains about ASPM
issues on such a system.
====================
net: phy: print warning if usage of deprecated array-style fixed-link binding is detected
The array-style fixed-link binding has been marked deprecated for more
than 10 yrs, but still there's a number of users. Print a warning when
usage of the deprecated binding is detected.
====================
net: phylink: warn if deprecated array-style fixed-link binding is used
The array-style fixed-link binding has been marked deprecated for more
than 10 yrs, but still there's a number of users. Print a warning when
usage of the deprecated binding is detected.
of: mdio: warn if deprecated fixed-link binding is used
The array-style fixed-link binding has been marked deprecated for more
than 10 yrs, but still there's a number of users. Print a warning when
usage of the deprecated binding is detected.
Both RSS and flow steering are properly installed, but the wait_port_listen
fails. Try to remove sleep(1) to see if the cause of the failure is
spending too much time during RX setup. I don't see a good reason to
have sleep in the first place. If there needs to be a delay between
installing the rules and receiving the traffic, let's add it to the
callers (devmem.py) instead.
As pointed out by Donald, when parsing an entry, the wrong type was set
for the temp value: this value is signed.
There are no real issues here, because the intermediate variable was
only wrong for the sign, not for the size, and the final variable had
the right sign. But this feels wrong, and is confusing, so fixing this
small typo introduced by commit ef0da3b8a2f1 ("mptcp: move address
attribute into mptcp_addr_info").
The client-side function connect_one_server() properly closes its IPC
descriptor after use, but the server-side code in both mptcp_sockopt.c
and mptcp_inq.c was missing corresponding close() calls for their IPC
descriptors, leaving file descriptors open unnecessarily.
This change ensures proper cleanup by:
1. Adding missing close(pipefds[0]/unixfds[0]) in server processes
2. Adding close(pipefds[1]/unixfds[1]) after server() function calls
This ensures both ends of the IPC pipe are properly closed in their
respective processes, preventing file descriptor leaks.
The server file descriptor ('fd') is opened in server() but never closed.
While accepted connections are properly closed in process_one_client(),
the main listening socket remains open, causing a resource leak.
This patch ensures the server fd is properly closed after processing
clients, bringing the sockopt and inq test cases in line with proper
resource cleanup practices.
Jakub Kicinski [Fri, 12 Sep 2025 16:17:03 +0000 (09:17 -0700)]
page_pool: always add GFP_NOWARN for ATOMIC allocations
Driver authors often forget to add GFP_NOWARN for page allocation
from the datapath. This is annoying to users as OOMs are a fact
of life, and we pretty much expect network Rx to hit page allocation
failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations
by default.
====================
Add PCS support for Renesas RZ/{T2H,N2H} SoCs
This series aims to add PCS support for the Renesas RZ/T2H and RZ/N2H SoCs
These SoCs include a MII converter (MIIC) that converts MII to RMII/RGMII
or can be set in pass-through mode for MII similar to the RZ/N1 SoC. The
MIIC is used in conjunction with the Ethernet switch (ETHSW) available on
these SoCs.
====================
Add support for the Renesas RZ/T2H MIIC by defining SoC-specific
modctrl match tables, register map, and string representations
for converters and ports.
net: pcs: rzn1-miic: Add per-SoC control for MIIC register unlock/lock
Make MIIC accessory register unlock/lock behaviour selectable via SoC/OF
data. Add init_unlock_lock_regs and miic_write to struct miic_of_data so
the driver can either perform the traditional global unlock sequence (as
used on RZ/N1) or use a different policy for other SoCs (for example
RZ/T2H, which does not require leaving registers unlocked).
miic_reg_writel() now calls the per-SoC miic_write callback to perform
register writes. Provide miic_reg_writel_unlocked() as the default writer
and set it for the RZ/N1 OF data so existing platforms keep the same
behaviour. Add a miic_unlock_regs() helper that implements the accessory
register unlock sequence so the unlock/lock sequence can be reused where
needed (for example when a SoC requires explicit unlock/lock around
individual accesses).
This change is preparatory work for supporting RZ/T2H.
Add reset-line handling to the RZN1 MIIC driver and move reset
configuration into the SoC/OF data. Introduce MIIC_MAX_NUM_RSTS (= 2),
add storage for reset_control_bulk_data in struct miic and add
reset_ids and reset_count fields to miic_of_data.
When reset_ids are present in the OF data, the driver obtains the reset
lines with devm_reset_control_bulk_get_exclusive(), deasserts them during
probe and registers a devres action to assert them on remove or on error.
This change is preparatory work to support the RZ/T2H SoC, which exposes
two reset lines for the ETHSS IP. The driver remains backward compatible
for platforms that do not provide reset lines.
net: pcs: rzn1-miic: Make switch mode mask SoC-specific
Move the hardcoded switch mode mask definition into the SoC-specific
miic_of_data structure. This allows each SoC to define its own mask
value rather than relying on a single fixed constant. For RZ/N1 the
mask remains GENMASK(4, 0).
This is in preparation for adding support for RZ/T2H, where the
switch mode mask is GENMASK(2, 0).
net: pcs: rzn1-miic: move port range handling into SoC data
Define per-SoC miic_port_start and miic_port_max fields in struct
miic_of_data and use them to validate the device-tree "reg" port number
and to compute the driver's internal zero-based port index as
(port - miic_port_start). Replace uses of the hard-coded MIIC_MAX_NR_PORTS
with the SoC-provided miic_port_max when iterating over ports.
On RZ/N1 the MIIC ports are numbered 1..5, whereas RZ/T2H numbers its MIIC
ports 0..3. By making the port base and range part of the OF data the
driver no longer assumes a fixed numbering scheme and can support SoCs that
enumerate ports from either zero or one and that expose different numbers
of ports.
This change is preparatory work for adding RZ/T2H support.
net: pcs: rzn1-miic: Move configuration data to SoC-specific struct
Move configuration data such as the modctrl matching table, converter
count, and string lookup tables into the SoC-specific miic_of_data
structure. Update the helper functions to use the per-SoC configuration
instead of relying on fixed-size arrays or global tables, and allocate
DT configuration memory dynamically.
This refactoring keeps the existing RZ/N1 support intact while preparing
the driver to handle the different configuration requirements of the
RZ/T2H SoC.
The pcs-rzn1-miic driver makes use of ARRAY_SIZE(), BIT() and GENMASK()
macros but does not explicitly include the headers where they are
defined. Add the missing <linux/array_size.h> and <linux/bits.h>
includes.
dt-bindings: net: pcs: renesas,rzn1-miic: Add RZ/T2H and RZ/N2H support
Add device tree binding support for RZ/T2H and RZ/N2H SoCs to the
existing RZ/N1 MIIC converter binding. These SoCs share similar MIIC
functionality but have architectural differences that require schema
updates.
Add new compatible strings "renesas,r9a09g077-miic" for RZ/T2H and
"renesas,r9a09g087-miic" for RZ/N2H, with the latter falling back to
the RZ/T2H variant. The new SoCs require reset support with two reset
lines for converter register reset and converter reset, which are not
present on RZ/N1.
Update port configurations to accommodate the different architectures.
RZ/N1 supports 5 ports numbered 1-5 with complex input mappings
covering indices 0-13, while RZ/T2H and RZ/N2H support 4 ports
numbered 0-3 with simplified input mappings covering indices 0-8.
Extend the switch port configuration property to support value 0 for
the new SoCs.
Add a new dt-bindings header file with media interface connection
matrix constants that map GMAC, ESC, and ETHSW ports to numeric
identifiers for use with RZ/T2H and RZ/N2H device trees.
Update DT schema validation to ensure proper port numbering and input
mappings per SoC variant.
tcp: reorganize tcp_sock_write_txrx group for variables later
Use the first 3-byte hole at the beginning of the tcp_sock_write_txrx
group for 'noneagle'/'rate_app_limited' to fill in the existing hole
in later patches. Therefore, the group size of tcp_sock_write_txrx is
reduced from 92 + 4 to 91 + 4. In addition, the group size of
tcp_sock_write_rx is changed to 96 to fit in the pahole outcome.
Below are the trimmed pahole outcomes before and after this patch:
Ilpo Järvinen [Thu, 11 Sep 2025 11:06:30 +0000 (13:06 +0200)]
tcp: fast path functions later
The following patch will use tcp_ecn_mode_accecn(),
TCP_ACCECN_CEP_INIT_OFFSET, TCP_ACCECN_CEP_ACE_MASK in
__tcp_fast_path_on() to make new flag for AccECN.
net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR
Clear EEE runtime flags when the PHY transitions to HALTED or ERROR
and the state machine drops the link. This avoids stale EEE state being
reported via ethtool after the PHY is stopped or hits an error.
This change intentionally only clears software runtime flags and avoids
MDIO accesses in HALTED/ERROR. A follow-up patch will address other
link state variables.
Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250912132000.1598234-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Victor Nogueira [Fri, 12 Sep 2025 15:46:16 +0000 (12:46 -0300)]
selftests/tc-testing: Adapt tc police action tests for Gb rounding changes
For the tc police action, iproute2 rounds up mtu and burst sizes to a
higher order representation. For example, if the user specifies the default
mtu for a police action instance (4294967295 bytes), iproute2 will output
it as 4096Mb when this action instance is dumped. After Jay's changes [1],
iproute2 will round up to Gb, so 4096Mb becomes 4Gb. With that in mind,
fix police's tc test output so that it works both with the current
iproute2 version and Jay's.
Signed-off-by: Victor Nogueira <victor@mojatatu.com> Reviewed-by: Cong Wang <cwang@multikernel.io> Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com> Link: https://patch.msgid.link/20250912154616.67489-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
dpll: zl3073x: Add support for devlink flash
Add functionality for accessing device hardware registers, loading
firmware bundles, and accessing the device's internal flash memory,
and use it to implement the devlink flash functionality.
====================
Ivan Vecera [Tue, 9 Sep 2025 09:15:32 +0000 (11:15 +0200)]
dpll: zl3073x: Implement devlink flash callback
Use the introduced functionality to read firmware files and flash their
contents into the device's internal flash memory to implement the devlink
flash update callback.
Ivan Vecera [Tue, 9 Sep 2025 09:15:30 +0000 (11:15 +0200)]
dpll: zl3073x: Add firmware loading functionality
Add functionality for loading firmware files provided by the vendor
to be flashed into the device's internal flash memory. The firmware
consists of several components, such as the firmware executable itself,
chip-specific customizations, and configuration files.
The firmware file contains at least a flash utility, which is executed
on the device side, and one or more flashable components. Each component
has its own specific properties, such as the address where it should be
loaded during flashing, one or more destination flash pages, and
the flashing method that should be used.
Ivan Vecera [Tue, 9 Sep 2025 09:15:29 +0000 (11:15 +0200)]
dpll: zl3073x: Add low-level flash functions
To implement the devlink device flash functionality, the driver needs
to access both the device memory and the internal flash memory. The flash
memory is accessed using a device-specific program (called the flash
utility). This flash utility must be downloaded by the driver into
the device memory and then executed by the device CPU. Once running,
the flash utility provides a flash API to access the flash memory itself.
During this operation, the normal functionality provided by the standard
firmware is not available. Therefore, the driver must ensure that DPLL
callbacks and monitoring functions are not executed during the flash
operation.
Add all necessary functions for downloading the utility to device memory,
entering and exiting flash mode, and performing flash operations.
Ivan Vecera [Tue, 9 Sep 2025 09:15:28 +0000 (11:15 +0200)]
dpll: zl3073x: Add functions to access hardware registers
Besides the device host registers that are directly accessible, there
are also hardware registers that can be accessed indirectly via specific
host registers.
Add register definitions for accessing hardware registers and provide
helper functions for working with them. Additionally, extend the number
of pages in the regmap configuration to 256, as the host registers used
for accessing hardware registers are located on page 255.
Add support for hardware PPS (Pulse Per Second) output to the
AMD XGBE driver. The implementation enables flexible periodic
output mode, exposing it via the PTP per_out interface.
The driver supports configuring PPS output using the standard
PTP subsystem, allowing precise periodic signal generation for
time synchronization applications.
The feature has been verified using the testptp tool and
oscilloscope.
Shenwei Wang [Wed, 10 Sep 2025 18:52:11 +0000 (13:52 -0500)]
net: fec: enable the Jumbo frame support for i.MX8QM
Certain i.MX SoCs, such as i.MX8QM and i.MX8QXP, feature enhanced
FEC hardware that supports Ethernet Jumbo frames with packet sizes
up to 16K bytes.
When Jumbo frames are supported, the TX FIFO may not be large enough
to hold an entire frame. To handle this, the FIFO is configured to
operate in cut-through mode when the frame size exceeds
(PKT_MAXBUF_SIZE - ETH_HLEN - ETH_FCS_LEN), which allows transmission
to begin once the FIFO reaches a certain threshold.
Shenwei Wang [Wed, 10 Sep 2025 18:52:10 +0000 (13:52 -0500)]
net: fec: add change_mtu to support dynamic buffer allocation
Add a fec_change_mtu() handler to recalculate the pagepool_order based on
the new_mtu value. And update the rx_frame_size accordingly when
pagepool_order changes.
MTU changes are only allowed when the adater is not running.
Shenwei Wang [Wed, 10 Sep 2025 18:52:09 +0000 (13:52 -0500)]
net: fec: add rx_frame_size to support configurable RX length
Add a new rx_frame_size member in the fec_enet_private structure to
track the RX buffer size. On the Jumbo frame enabled system, the value
will be recalculated whenever the MTU is updated, allowing the driver
to allocate RX buffer efficiently.
Configure the TRUNC_FL (Frame Truncation Length) based on the smaller
value between max_buf_size and the rx_frame_size to maintain consistent
RX error behavior, regardless of whether Jumbo frames are enabled.
Shenwei Wang [Wed, 10 Sep 2025 18:52:08 +0000 (13:52 -0500)]
net: fec: update MAX_FL based on the current MTU
Configure the MAX_FL (Maximum Frame Length) register according to the
current MTU value, which ensures that packets exceeding the configured MTU
trigger an RX error.
Shenwei Wang [Wed, 10 Sep 2025 18:52:07 +0000 (13:52 -0500)]
net: fec: add pagepool_order to support variable page size
Add a new pagepool_order member in the fec_enet_private struct
to allow dynamic configuration of page size for an instance. This
change clears the hardcoded page size assumptions.
Shenwei Wang [Wed, 10 Sep 2025 18:52:06 +0000 (13:52 -0500)]
net: fec: use a member variable for maximum buffer size
Refactor code to support Jumbo frame functionality by adding a member
variable in the fec_enet_private structure to store PKT_MAXBUF_SIZE.
Remove the OPT_FRAME_SIZE and define a new macro OPT_ARCH_HAS_MAX_FL to
indicate architectures that support configurable maximum frame length.
And update the MAX_FL register value to max_buf_size when
OPT_ARCH_HAS_MAX_FL is defined as 1.
Jakub Kicinski [Sun, 14 Sep 2025 20:13:12 +0000 (13:13 -0700)]
Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue
Tony Nguyen says:
====================
Fwlog support in ixgbe
Michal Swiatkowski says:
Firmware logging is a feature that allow user to dump firmware log using
debugfs interface. It is supported on device that can handle specific
firmware ops. It is true for ice and ixgbe driver.
Prepare code from ice driver to be moved to the library code and reuse
it in ixgbe driver.
* '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
ixgbe: fwlog support for e610
ice, libie: move fwlog code to libie
ice: reregister fwlog after driver reinit
ice: prepare for moving file to libie
ice: move debugfs code to fwlog
libie, ice: move fwlog admin queue to libie
ice: drop driver specific structure from fwlog code
ice: check for PF number outside the fwlog code
ice: move out debugfs init from fwlog
ice: allow calling custom send function in fwlog
ice: add pdev into fwlog structure and use it for logging
ice: introduce ice_fwlog structure
ice: drop ice_pf_fwlog_update_module()
ice: move get_fwlog_data() to fwlog file
ice: make fwlog functions static
====================
Jakub Kicinski [Sun, 14 Sep 2025 20:00:56 +0000 (13:00 -0700)]
Merge branch 'pru-icssm-ethernet-driver'
Parvathi Pudi says:
====================
PRU-ICSSM Ethernet Driver
The Programmable Real-Time Unit Industrial Communication Sub-system (PRU-ICSS)
is available on the TI SOCs in two flavors: Gigabit ICSS (ICSSG) and the older
Megabit ICSS (ICSSM).
Support for ICSSG Dual-EMAC mode has already been mainlined [1] and the
fundamental components/drivers such as PRUSS driver, Remoteproc driver,
PRU-ICSS INTC, and PRU-ICSS IEP drivers are already available in the mainline
Linux kernel. The current set of patch series builds on top of these components
and introduces changes to support the Dual-EMAC using ICSSM on the TI AM57xx,
AM437x and AM335x devices.
AM335x, AM437x and AM57xx devices may have either one or two PRU-ICSS instances
with two 32-bit RISC PRU cores. Each PRU core has (a) dedicated Ethernet interface
(MII, MDIO), timers, capture modules, and serial communication interfaces, and
(b) dedicated data and instruction RAM as well as shared RAM for inter PRU
communication within the PRU-ICSS.
These patches add support for basic RX and TX functionality over PRU Ethernet
ports in Dual-EMAC mode.
Further, note that these are the initial set of patches for a single instance of
PRU-ICSS Ethernet. Additional features such as Ethtool support, VLAN Filtering,
Multicast Filtering, Promiscuous mode, Storm prevention, Interrupt coalescing,
Linux PTP (ptp4l) Ordinary clock and Switch mode support for AM335x, AM437x
and AM57x along with support for a second instance of PRU-ICSS on AM57x
will be posted subsequently.
The patches presented in this series have gone through the patch verification
tools and no warnings or errors are reported. Sample test logs obtained from AM33x,
AM43x and AM57x verifying the functionality on Linux next kernel are available here:
Roger Quadros [Fri, 12 Sep 2025 11:53:28 +0000 (17:23 +0530)]
net: ti: icssm-prueth: Adds link detection, RX and TX support.
Changes corresponding to link configuration such as speed and duplexity.
IRQ and handler initializations are performed for packet reception.Firmware
receives the packet from the wire and stores it into OCMC queue. Next, it
notifies the CPU via interrupt. Upon receiving the interrupt CPU will
service the IRQ and packet will be processed by pushing the newly allocated
SKB to upper layers.
When the user application want to transmit a packet, it will invoke
sys_send() which will in turn invoke the PRUETH driver, then it will write
the packet into OCMC queues. PRU firmware will pick up the packet and
transmit it on to the wire.
Reviewed-by: Mohan Reddy Putluru <pmohan@couthit.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com> Signed-off-by: Parvathi Pudi <parvathi@couthit.com> Link: https://patch.msgid.link/20250912115443.529856-5-parvathi@couthit.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Roger Quadros [Fri, 12 Sep 2025 11:53:27 +0000 (17:23 +0530)]
net: ti: icssm-prueth: Adds PRUETH HW and SW configuration
Updates for MII_RT hardware peripheral configuration such as RX and TX
configuration for PRU0 and PRU1, frame sizes, and MUX config.
Updates for PRU-ICSS firmware register configuration and DRAM, SRAM and
OCMC memory initialization, which will be used in the runtime for packet
reception and transmission.
DUAL-EMAC memory allocation for software queues and its supporting
components such as the buffer descriptors and queue descriptors. These
software queues are placed in OCMC memory and are shared with CPU by
PRU-ICSS for packet receive and transmit.
All declarations and macros are being used from common header file
for various protocols.
Reviewed-by: Mohan Reddy Putluru <pmohan@couthit.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com> Signed-off-by: Parvathi Pudi <parvathi@couthit.com> Link: https://patch.msgid.link/20250912115443.529856-4-parvathi@couthit.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Roger Quadros [Fri, 12 Sep 2025 10:44:51 +0000 (16:14 +0530)]
net: ti: icssm-prueth: Adds ICSSM Ethernet driver
Updates Kernel configuration to enable PRUETH driver and its dependencies
along with makefile changes to add the new PRUETH driver.
Changes includes init and deinit of ICSSM PRU Ethernet driver including
net dev registration and firmware loading for DUAL-MAC mode running on
PRU-ICSS2 instance.
Changes also includes link handling, PRU booting, default firmware loading
and PRU stopping using existing remoteproc driver APIs.
Reviewed-by: Mohan Reddy Putluru <pmohan@couthit.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com> Signed-off-by: Parvathi Pudi <parvathi@couthit.com> Link: https://patch.msgid.link/20250912104741.528721-3-parvathi@couthit.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dt-bindings: net: ti: Adds DUAL-EMAC mode support on PRU-ICSS2 for AM57xx, AM43xx and AM33xx SOCs
Documentation update for the newly added "pruss2_eth" device tree
node and its dependencies along with compatibility for PRU-ICSS
Industrial Ethernet Peripheral (IEP), PRU-ICSS Enhanced Capture
(eCAP) peripheral and using YAML binding document for AM57xx SoCs.
This series cleans up the hardware timestamping / PTP initialisation
and cleanup code in the stmmac driver. Several key points in no
particular order:
1. Golden rule: unregister first, then release resources.
stmmac_release_ptp didn't do this.
2. Avoid leaking resources - __stmmac_open() failure leaves the
timestamping support initialised, but stops its clock. Also
violates (1).
3. Avoid double-release of resources - stmmac_open() followed by
stmmac_xdp_open() failing results in the PTP clock prepare and
enable counts being released, and if the interface is then
brought down, they are incorrectly released again. As XDP
doesn't gain any additional prepare/enables on the PTP clock,
remove this incorrect cleanup.
4. Changing the MTU of the interface is disruptive to PTP, and
remains so as long as. This is not fixed by this series (too
invasive at the moment.)
5. Avoid exporting functions that aren't used...
6. Avoid unnecessary runtime PM state manipulations (no point
manipulating this when MTU changes).
7. Make the PTP/timestamping initialisation more readable - no
point calling functions in the same file from one callsite
that return error codes from one location in the called function,
to only have the sole callee print messages depending on that
return code. Also simplifying the mess in stmmac_hw_setup().
Also placing support checks in a better location. Also getting
rid of the "ptp_register" boolean through this restructuring.
v1 was tested by Gatien CHEVALLIER - thanks.
====================
Russell King (Oracle) [Thu, 11 Sep 2025 11:10:28 +0000 (12:10 +0100)]
net: stmmac: move timestamping/ptp init to stmmac_hw_setup() caller
Move the call to stmmac_init_timestamping() or stmmac_setup_ptp() out
of stmmac_hw_setup() to its caller after stmmac_hw_setup() has
successfully completed. This slightly changes the ordering during
setup, but should be safe to do.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Thu, 11 Sep 2025 11:10:18 +0000 (12:10 +0100)]
net: stmmac: add stmmac_setup_ptp()
Add a function to setup PTP, which will enable the clock, initialise
the timestamping, and register with the PTP clock subsystem. Call this
when we want to register the PTP clock in stmmac_hw_setup(), otherwise
just call the
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Thu, 11 Sep 2025 11:10:13 +0000 (12:10 +0100)]
net: stmmac: rename stmmac_init_ptp()
Changes to the stmmac driver to fix various issues with PTP have made
stmmac_init_ptp() less about initialising the entire PTP block, and
now primarily deals with the packet timestamping support. The exception
to this is ptp_clk_freq_config(), which is an odditiy. It remains
as stmmac_init_ptp() is used both at .ndo_open() time and in the
resume paths.
However, restructuring this code to make it more easily readable makes
the continued use of "init_ptp" confusing.
In preparation to cleaning up the (re-)initialisation of timestamping,
rename the existing stmmac_init_ptp() to stmmac_init_timestamping()
which better reflects its functionality.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Thu, 11 Sep 2025 11:10:02 +0000 (12:10 +0100)]
net: stmmac: add __stmmac_release() to complement __stmmac_open()
Rename stmmac_release() to __stmmac_release(), providing a new
stmmac_release() method. Update stmmac_change_mtu() to use
__stmmac_release(). Move the runtime PM handling into stmmac_open()
and stmmac_release().
This avoids stmmac_change_mtu() needlessly fiddling with the runtime
PM state, and will allow future changes to remove code from
__stmmac_open() and __stmmac_release() that should only happen when
the net device is administratively brought up or down.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nothing outside of stmmac_main.c makes use of
stmmac_init_tstamp_counter(), so there's no point exporting it for
modules, or even having it non-static. Remove the export and make
it static.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Neither stmmac_xdp_release() nor the normal paths of stmmac_xdp_open()
touch clk_ptp_ref, so stmmac_xdp_open() should not be doing anything
with this clock. However, in its error path, it calls
stmmac_hw_teardown() which disables and unprepares this clock, which
can lead to the clock state becoming unbalanced when the netdev is
taken administratively down.
Remove this call to stmmac_hw_teardown(), and as this is the last user
of this function, remove the function as well.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Thu, 11 Sep 2025 11:09:47 +0000 (12:09 +0100)]
net: stmmac: fix PTP error cleanup in __stmmac_open()
The cleanup function for stmmac_setup_ptp() is stmmac_release_ptp()
which entirely undoes the effects of stmmac_setup_ptp() by
unregistering the PTP device and then stopping the PTP clock,
whereas stmmac_hw_teardown() will only stop the PTP clock while
leaving the PTP device registered.
This can lead to a kernel oops - if __stmmac_open() fails after
registering the PTP clock, the PTP device will remain registered,
and if the module is removed, subsequent PTP device accesses will
lead to a kernel oops.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King (Oracle) [Thu, 11 Sep 2025 11:09:42 +0000 (12:09 +0100)]
net: stmmac: disable PTP clock after unregistering PTP
Follow the principle of unpublish from userspace and then teardown
resources.
Disable the PTP clock only after unregistering with the PTP subsystem,
which ensures that we only stop the clock that ticks the timesource
after we have removed the PTP device.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
projects / users / hch / misc.git / log