* RE: [PATCH iwl-net v1] idpf: fix lan_regs leak on core init failure
From: Jagielski, Jedrzej @ 2026-07-06 9:12 UTC (permalink / raw)
To: xuanqiang.luo@linux.dev, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
Hay, Joshua A, Nikolova, Tatyana E, Xuanqiang Luo
In-Reply-To: <20260703104132.47419-1-xuanqiang.luo@linux.dev>
From: xuanqiang.luo@linux.dev <xuanqiang.luo@linux.dev>
Sent: Friday, July 3, 2026 12:42 PM
>From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>
>idpf_vc_core_init() gets the LAN memory region layout before mapping the
>regions and allocating vport resources. Both layout paths allocate
>hw->lan_regs, but later error paths return without freeing it.
>
>idpf_vc_core_deinit() does not cover these paths because it returns unless
>IDPF_VC_CORE_INIT is set, and that bit is set only after core init
>succeeds.
>
>Free hw->lan_regs on the post-allocation error paths and clear the
>pointer and region count.
>
>Fixes: 6aa53e861c1a ("idpf: implement get LAN MMIO memory regions")
>Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Looks fine, thanks for the patch!
Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ti: icssm-prueth: Add HSR and PRP HW offload mode support for AM57xx, AM437x and AM335x
From: Paolo Abeni @ 2026-07-06 9:13 UTC (permalink / raw)
To: parvathi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260630124958.894360-2-parvathi@couthit.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
Subject: net: ti: icssm-prueth: Add HSR and PRP HW offload mode support for AM57xx, AM437x and AM335x
This commit introduces hardware offload support for the HSR and PRP redundancy
protocols on TI PRU-ICSS Ethernet MACs. It enables firmware-based frame
duplicate detection and L2 forwarding, treating PRU Ethernet ports as Link
Redundancy Entity (LRE) slaves. The driver can now dynamically switch between
dual-EMAC, switch, and HSR/PRP modes.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
[ ... ]
> @@ -564,7 +592,7 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac *emac,
[ ... ]
> /* update first buffer descriptor */
> wr_buf_desc = (pktlen << PRUETH_BD_LENGTH_SHIFT) &
> PRUETH_BD_LENGTH_MASK;
> + if (PRUETH_IS_HSR(prueth))
> + wr_buf_desc |= BIT(PRUETH_BD_HSR_FRAME_SHIFT);
[Severity: High]
Does padding small packets with eth_skb_pad() in icssm_emac_ndo_start_xmit()
interfere with PRP trailer detection here?
When a short PRP frame is padded to 60 bytes in icssm_emac_ndo_start_xmit(),
the zero-padding is appended after the RCT. Later, in
icssm_prueth_tx_enqueue(), the driver attempts to read the RCT like this:
struct prp_txopt_rct *rct =
(struct prp_txopt_rct *)(skb_tail_pointer(skb) - ICSSM_LRE_TAG_SIZE);
Won't this calculation point into the trailing zero-padding instead of the
actual RCT? This would cause small PRP frames to bypass redundancy
duplication.
[ ... ]
> @@ -912,6 +963,25 @@ static int icssm_emac_request_irqs(struct prueth_emac *emac)
> return ret;
> }
>
> +static int icssm_emac_sanitize_feature_flags(struct prueth_emac *emac)
> +{
> + netdev_features_t request_lre;
> +
> + request_lre = emac->ndev->features & NETIF_PRUETH_LRE_OFFLOAD_FEATURES;
> +
> + if (prueth_is_lre(emac->prueth) && !request_lre) {
> + netdev_err(emac->ndev, "Error: Turn ON HSR offload\n");
> + return -EINVAL;
> + }
[Severity: Medium]
Is this check sufficient to handle partial feature toggling?
If a user disables NETIF_F_HW_HSR_TAG_RM via ethtool while leaving
NETIF_F_HW_HSR_FWD active, request_lre will still evaluate to non-zero and
bypass this validation. Since the firmware unconditionally strips the tag,
could this mismatched configuration cause the software stack to misinterpret
the inner IP header as an HSR tag?
[ ... ]
> @@ -1079,6 +1162,9 @@ static int icssm_emac_ndo_stop(struct net_device *ndev)
> else
> rproc_shutdown(emac->pru);
>
> + if (prueth_is_lre(prueth))
> + icssm_prueth_lre_cleanup(prueth);
[Severity: High]
Could this unconditionally cancel the global HSR/PRP duplicate table check
timer while the other LRE port is still running?
If eth0 is brought down, the timer is canceled here, but if eth1 remains
active, the duplication tables could silently fill up and drop legitimate
frames because the check timer is never restarted.
[ ... ]
> @@ -1122,7 +1208,8 @@ static int icssm_prueth_change_mode(struct prueth *prueth,
> }
> }
>
> - if (mode == PRUSS_ETHTYPE_EMAC || mode == PRUSS_ETHTYPE_SWITCH) {
> + if (mode == PRUSS_ETHTYPE_EMAC || mode == PRUSS_ETHTYPE_SWITCH ||
> + mode == PRUSS_ETHTYPE_HSR || mode == PRUSS_ETHTYPE_PRP) {
[Severity: High]
This is a pre-existing issue, but can the direct invocation of ndo_open() and
ndo_stop() inside icssm_prueth_change_mode() cause a deadlock?
If ndev->netdev_ops->ndo_open(ndev) fails and returns an error, the function
aborts without restoring the NAPI state. Later, when the interface is brought
down, the kernel naturally invokes ndo_stop() again. A second napi_disable()
call on an already disabled NAPI might trigger an infinite sleep waiting for
NAPI_STATE_SCHED.
[ ... ]
> @@ -1360,6 +1465,8 @@ static void icssm_emac_ndo_set_rx_mode(struct net_device *ndev)
[ ... ]
> /* It is a shared table. So lock the access */
> - spin_lock_irqsave(&emac->addr_lock, flags);
> + spin_lock_irqsave(mc_filter_tbl_lock, flags);
>
> /* Disable and reset multicast filter, allows allmulti */
> icssm_emac_mc_filter_ctrl(emac, false);
[Severity: High]
Does this function corrupt the shared multicast hardware filter table in LRE
mode?
By calling icssm_emac_mc_filter_reset() the shared table in DRAM1 is cleared.
The code then repopulates the table by iterating only over the current
net_device's multicast addresses. Could this silently drop multicast traffic
for the other active slave port since its addresses are wiped out?
[ ... ]
> +static int icssm_prueth_hsr_port_link(struct net_device *ndev,
> + struct net_device *hsr_ndev)
> +{
[ ... ]
> + spin_lock_irqsave(&emac->addr_lock, flags);
> +
> + if (!prueth->hsr_members) {
[Severity: Low]
Is the per-port emac->addr_lock the correct lock to use when modifying the
device-wide shared state in prueth->hsr_members and prueth->hsr_dev?
While the networking core's global rtnl_lock might serialize this path during
NETDEV_CHANGEUPPER, using a local instance lock to protect global state could
be a maintainability hazard.
[ ... ]
> +free_hsr:
> + spin_lock_irqsave(&emac->addr_lock, flags);
> +
> + prueth->hsr_dev = NULL;
> + prueth->hsr_members &= ~BIT(emac->port_id);
> +
> + spin_unlock_irqrestore(&emac->addr_lock, flags);
> + return ret;
> +}
[Severity: High]
If adding the second HSR/PRP port fails (e.g., during
icssm_prueth_change_mode), does this error path corrupt the bridge state?
Unconditionally clearing the shared prueth->hsr_dev pointer while the first
port is still present in prueth->hsr_members appears to permanently break
subsequent link attempts for the second port, because future links will fail
on the earlier condition:
if (prueth->hsr_dev != hsr_ndev)
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: ti: icssm-prueth: Add priority based RX IRQ handlers
From: Paolo Abeni @ 2026-07-06 9:13 UTC (permalink / raw)
To: parvathi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260630124958.894360-3-parvathi@couthit.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
net: ti: icssm-prueth: Add priority based RX IRQ handlers
This patch adds support for priority based interrupt handling for the STP/
RSTP Switch, HSR and PRP protocols along with extra logic to address first
come first served to avoid port dominance. The driver will read the RX HW
timestamp from the frame to achieve wire-arrival ordering.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
[ ... ]
> @@ -1188,26 +1188,26 @@ static int icssm_emac_ndo_stop(struct net_device *ndev)
> /* disable the mac port */
> icssm_prueth_port_enable(emac, false);
>
> + netif_stop_queue(ndev);
> +
> /* stop PHY */
> phy_stop(emac->phydev);
>
> - napi_disable(&emac->napi);
> hrtimer_cancel(&emac->tx_hrtimer);
>
[ ... ]
> /* stop the PRU */
> if (!PRUETH_IS_EMAC(prueth))
> icssm_prueth_sw_shutdown_prus(emac, ndev);
>
> if (prueth_is_lre(prueth))
> icssm_prueth_lre_cleanup(prueth);
[Severity: High]
This is a pre-existing issue, but is the LRE duplicate detection timer
prematurely canceled when a single port goes down?
In icssm_emac_ndo_stop, icssm_prueth_lre_cleanup is called unconditionally
when any interface is brought down.
If one port in the HSR/PRP bridge goes down while the other remains active,
this cancels the shared tbl_check_timer, potentially causing duplicate
frames to stop being detected and dropped by the hardware.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth_common.c b/drivers/net/ethernet/ti/icssm/icssm_prueth_common.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth_common.c
> @@ -0,0 +1,286 @@
[ ... ]
> +static int icssm_prueth_common_emac_rx_packets(struct prueth_emac *emac,
> + int quota, u8 qid1, u8 qid2)
> +{
[ ... ]
> + if ((*pkt_info_p).length < EMAC_MIN_PKTLEN) {
> + /* Undersized frame: firmware should have filtered
> + * these before they reach the host queue. Advance
> + * the read pointer to skip it.
> + */
> + update_rd_ptr = *bd_wr_ptr_p;
> + ndevstats_p->rx_length_errors++;
[Severity: High]
This is a pre-existing issue, but does this error path flush the entire
pending RX queue?
When the driver detects an undersized or oversized packet, it attempts to
skip it by updating the read pointer. However, setting update_rd_ptr to
*bd_wr_ptr_p appears to assign the hardware's write pointer (the very end of
the queue), rather than advancing by one descriptor.
Could this discard all pending descriptors instead of just the malformed one?
[Severity: High]
Does this introduce a race condition on the network statistics?
This patch introduces split NAPI polling with separate priority threads
(napi_hpq and napi_lpq) that process the high and low priority queues across
both physical ports. These NAPI instances can be scheduled on different CPUs
concurrently.
Both instances invoke icssm_prueth_common_emac_rx_packets, which updates raw
unsigned long statistics like ndevstats_p->rx_length_errors (and 64-bit
stats like emac->stats.rx_bytes in icssm_emac_rx_packet) using += without
atomic instructions or locks.
On 32-bit platforms, could this cause lost updates for concurrent writers, or
torn reads when read by ndo_get_stats64?
> + } else if ((*pkt_info_p).length > EMAC_MAX_FRM_SUPPORT) {
> + /* Oversized frame: firmware should have filtered
> + * these before they reach the host queue. Advance
> + * the read pointer to skip it.
> + */
> + update_rd_ptr = *bd_wr_ptr_p;
> + ndevstats_p->rx_length_errors++;
> + } else {
> + update_rd_ptr = *bd_rd_ptr_p;
> + ret = icssm_emac_rx_packet(emac_p, &update_rd_ptr,
> + pkt_info_p, rxqueue_p);
> + if (ret)
> + return used;
[Severity: High]
This is a pre-existing issue, but does a memory allocation failure in this RX
path cause a permanent RX queue stall?
If icssm_emac_rx_packet fails to allocate an SKB, it returns -ENOMEM. The
driver immediately aborts the NAPI polling loop without updating the hardware
read pointer or consuming the packet.
Because it returns used (which is less than budget), it triggers
napi_complete_done() which re-enables the RX interrupt. Since the packet is
still pending in the hardware queue, the interrupt fires again immediately in
an infinite loop.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c b/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c
> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth_lre.c
> @@ -152,6 +152,14 @@ static void icssm_prueth_lre_protocol_init(struct prueth *prueth)
> dram1 + ICSS_LRE_SUP_ADDR_LOW);
> }
>
> +static void icssm_prueth_lre_config_packet_timestamping(struct prueth *prueth)
> +{
> + void __iomem *sram = prueth->mem[PRUETH_MEM_SHARED_RAM].va;
> +
> + writeb(1, sram + ICSS_LRE_PRIORITY_INTRS_STATUS_OFFSET);
> + writeb(1, sram + ICSS_LRE_TIMESTAMP_PKTS_STATUS_OFFSET);
> +}
> +
[ ... ]
> @@ -202,6 +210,11 @@ void icssm_prueth_lre_config(struct prueth *prueth)
> icssm_prueth_lre_init(prueth);
> icssm_prueth_lre_dbg_init(prueth);
> icssm_prueth_lre_protocol_init(prueth);
> + /* Enable per-packet timestamping so the driver can order
> + * received frames by arrival time across the two slave ports.
> + */
> + icssm_prueth_lre_config_packet_timestamping(prueth);
> +
> }
[Severity: High]
Does this fail to enable hardware timestamping in Switch mode?
The patch introduces timestamp-based packet ordering for Switch, HSR, and PRP
modes, requiring configuration via ICSS_LRE_PRIORITY_INTRS_STATUS_OFFSET and
ICSS_LRE_TIMESTAMP_PKTS_STATUS_OFFSET.
However, icssm_prueth_lre_config_packet_timestamping is only called from
icssm_prueth_lre_config, which is gated by prueth_is_lre() (only true for HSR
and PRP).
In Switch mode, these registers appear to never be written, potentially
leaving timestamps disabled in firmware and breaking the wire-arrival
ordering logic.
[Severity: High]
This is a pre-existing issue, but are the dynamically allocated FDB learning
work items tracked for cleanup?
When learning a new source MAC address in icssm_prueth_sw_learn_fdb()
(drivers/net/ethernet/ti/icssm/icssm_prueth_switch.c), the driver dynamically
allocates a struct icssm_prueth_sw_fdb_work and queues it.
If these are not tracked in a list, unloading the module could leave pending
work items that execute unmapped memory, potentially causing a kernel panic.
[Severity: High]
This is a pre-existing issue, but can the unbounded GFP_ATOMIC allocations
for FDB learning lead to memory exhaustion?
Every received frame with an unlearned source MAC address triggers
icssm_prueth_sw_learn_fdb(), which uses kzalloc_obj(..., GFP_ATOMIC) without
rate limiting.
A continuous flood of frames with randomized source MAC addresses could
trigger thousands of allocations per second, potentially exhausting the
kernel's atomic memory pools.
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
From: Paolo Abeni @ 2026-07-06 9:13 UTC (permalink / raw)
To: parvathi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260630124958.894360-4-parvathi@couthit.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/
---
net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
This commit introduces hardware duplicate offload for HSR and PRP modes. It
implements a common shared queue between the two ports, writing frames once
to OCMC RAM and relying on the firmware to replicate the transmission.
> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> index 2ab78a98f8568..cbe666a212c3b 100644
> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
> @@ -97,6 +125,17 @@ static void icssm_prueth_write_reg(struct prueth *prueth,
> static enum pruss_mem pruss_mem_ids[] = { PRUSS_MEM_DRAM0, PRUSS_MEM_DRAM1,
> PRUSS_MEM_SHRD_RAM2 };
>
> +struct prp_txopt_rct {
> + __be16 sequence_nr;
> + __be16 lan_id_and_lsdu_size;
> + __be16 prp_suffix;
> +};
[Severity: High]
Does this structure definition need the __packed attribute?
This struct consists of three 16-bit fields but lacks the __packed attribute,
so it inherits a 2-byte alignment requirement. Later in
icssm_prueth_tx_enqueue, a pointer to this structure is derived directly
from skb_tail_pointer.
If an ethernet frame payload has an odd byte length, wouldn't casting and
dereferencing this pointer cause an unaligned 16-bit memory access, resulting
in hardware traps or panics on architectures that do not support it?
[ ... ]
> @@ -549,15 +588,24 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac *emac,
[ ... ]
> + other_emac = emac->prueth->emac[(emac->port_id == PRUETH_PORT_MII0) ?
> + PRUETH_PORT_MII1 - 1 : PRUETH_PORT_MII0 - 1];
> +
> + if (prueth_is_lre(prueth) && (emac->link || other_emac->link))
> + link_up = true;
[Severity: High]
Could this logical OR cause the shared transmission queue to stall completely
if only one of the slave links goes down?
If one port loses its link, its emac->link is 0, but the other active port
will still evaluate link_up as true. The active port would continue sending
duplicate frames to the shared queue.
[ ... ]
> @@ -605,6 +659,29 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac *emac,
[ ... ]
> + if (free_blocks_other_port < free_blocks)
> + free_blocks = free_blocks_other_port;
> + }
[Severity: High]
Following up on the link_up logic above, since the available queue space is
bounded by the slowest reader here, wouldn't the inactive port's read pointer
remain frozen?
This appears to exhaust the free_blocks pool, causing the active port to
eventually spin and return -ENOBUFS permanently, defeating the redundancy.
[ ... ]
> + } else {
> + /* Read PRP RCT to extract sequence number and LAN ID */
> + struct prp_txopt_rct *rct =
> + (struct prp_txopt_rct *)(skb_tail_pointer(skb) -
> + ICSSM_LRE_TAG_SIZE);
> +
> + if (rct->prp_suffix == htons(ETH_P_PRP)) {
[Severity: High]
Is it safe to directly dereference rct->prp_suffix here?
As mentioned above regarding the struct definition, this might lead to an
unaligned memory access on certain architectures. Perhaps using the
get_unaligned_be16 helper would be safer here, or adding the __packed
attribute to the structure definition.
[ ... ]
> @@ -1341,18 +1516,30 @@ static enum netdev_tx icssm_emac_ndo_start_xmit(struct sk_buff *skb,
[ ... ]
> + raw_spin_lock(lock_queue);
> + ret = icssm_prueth_tx_enqueue(emac, skb, qid);
> + raw_spin_unlock(lock_queue);
[Severity: High]
Does this need to use the irqsave variant to protect against cross-device
deadlocks with netpoll?
The lre_host_queue_lock is shared between the two ports. If a hardirq
preempts a CPU while it holds this lock during a transmission, and the
interrupt handler invokes a printk that triggers netconsole over the second
interface, netpoll might bypass the netif_tx_lock.
When the second interface calls into ndo_start_xmit, it would attempt to
acquire the exact same lre_host_queue_lock, causing it to spin forever on
the same CPU.
--
This is an AI-generated review.
^ permalink raw reply
* [PATCH v2 0/5] ARM: rockchip: rv1126: Add support for Alientek ATK-DLRV1126
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
The ATK-DLRV1126 board consists of a CLRV1126F core module and a
DLRV1126 carrier board. The core module contains the Rockchip RV1126
SoC, eMMC and RK809 PMIC. The carrier board provides Gigabit Ethernet,
SD card, AP6212 WiFi and Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and
audio connectors.
This series adds the Alientek vendor prefix and board compatible, updates
the Motorcomm PHY driver to consume an optional external PHY reference
clock, adds missing RV1126 SoC description pieces, and finally adds the
CLRV1126F core module and DLRV1126 carrier board device trees.
The board was tested with Ethernet/NFS boot, eMMC, SD card, SDIO WiFi
enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and RK809
audio card registration.
Changes in v2:
- Model CLK_GMAC_ETHERNET_OUT as an external PHY clock consumed by the
YT8531 PHY instead of keeping it alive from dwmac-rk.
- Add optional clock enable support to the YT8531 path in the Motorcomm
PHY driver.
- Use phy-mode = "rgmii-id" for the Alientek DLRV1126 GMAC.
- Keep the PHY reference clock in the ethernet-phy node, following the
rk3588-tiger.dtsi pattern.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Yanan He (5):
dt-bindings: vendor-prefixes: add alientek
dt-bindings: arm: rockchip: Add Alientek DLRV1126
net: phy: motorcomm: Enable optional clock for YT8531
ARM: dts: rockchip: Add RV1126 I2C5
ARM: dts: rockchip: Add Alientek DLRV1126
.../devicetree/bindings/arm/rockchip.yaml | 7 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 256 +++++++++++++++++++
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 +
arch/arm/boot/dts/rockchip/rv1126.dtsi | 15 ++
drivers/net/phy/motorcomm.c | 7 +
8 files changed, 575 insertions(+)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260618-rv1126-alientek-dlrv1126-d94abdcf8580
Best regards,
--
Yanan He <grumpycat921013@gmail.com>
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: vendor-prefixes: add alientek
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
Add a vendor prefix for Alientek, a board and module vendor used by the
ATK-DLRV1126 board.
Link: https://en.alientek.com
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7..914d5a8fd628 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -88,6 +88,8 @@ patternProperties:
description: ALFA Network Inc.
"^algoltek,.*":
description: AlgolTek, Inc.
+ "^alientek,.*":
+ description: Guangzhou Xingyi Intelligent Technology Co., Ltd.
"^allegro,.*":
description: Allegro DVT
"^allegromicro,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/5] dt-bindings: arm: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
The board consists of a DLRV1126 carrier board and a CLRV1126F core
module based on the Rockchip RV1126 SoC.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d..9058f2a461d5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -162,6 +162,13 @@ properties:
- const: coolpi,pi-4b
- const: rockchip,rk3588s
+ - description: Alientek CLRV1126F SoM based boards
+ items:
+ - enum:
+ - alientek,dlrv1126
+ - const: alientek,clrv1126f
+ - const: rockchip,rv1126
+
- description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
items:
- const: edgeble,neural-compute-module-2-io # Edgeble Neural Compute Module 2 IO Board
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/5] net: phy: motorcomm: Enable optional clock for YT8531
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
Some boards feed the YT8531 PHY from an SoC-provided external
reference clock described by the common ethernet-phy "clocks" property.
Enable the optional PHY clock during probe so boards can model this
clock as a PHY input instead of keeping the clock alive from the MAC
driver.
This is needed on the Alientek DLRV1126, where the PHY reference clock
is provided by CLK_GMAC_ETHERNET_OUT.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
drivers/net/phy/motorcomm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c
index 5071605a1a11..3396a38cfc0f 100644
--- a/drivers/net/phy/motorcomm.c
+++ b/drivers/net/phy/motorcomm.c
@@ -6,6 +6,7 @@
* Author: Frank <Frank.Sae@motor-comm.com>
*/
+#include <linux/clk.h>
#include <linux/etherdevice.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -1180,9 +1181,15 @@ static int yt8521_probe(struct phy_device *phydev)
static int yt8531_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
+ struct clk *clk;
u16 mask, val;
u32 freq;
+ clk = devm_clk_get_optional_enabled(dev, NULL);
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get and enable PHY clock\n");
+
if (device_property_read_u32(dev, "motorcomm,clk-out-frequency-hz", &freq))
freq = YTPHY_DTS_OUTPUT_CLK_DIS;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: rockchip: Add RV1126 I2C5
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
The controller is present in the SoC and can be used by boards for
external peripherals, such as an RTC on the Alientek DLRV1126 carrier
board.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 ++++++++++
arch/arm/boot/dts/rockchip/rv1126.dtsi | 15 +++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index 35ef6732281f..1d883b80aed4 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -123,6 +123,16 @@ i2c3m2_xfer: i2c3m2-xfer {
<1 RK_PD7 3 &pcfg_pull_none>;
};
};
+ i2c5 {
+ /omit-if-no-ref/
+ i2c5m0_xfer: i2c5m0-xfer {
+ rockchip,pins =
+ /* i2c5_scl_m0 */
+ <2 RK_PA5 7 &pcfg_pull_none_drv_level_0_smt>,
+ /* i2c5_sda_m0 */
+ <2 RK_PB3 7 &pcfg_pull_none_drv_level_0_smt>;
+ };
+ };
i2s0 {
i2s0m0_lrck_tx: i2s0m0-lrck-tx {
rockchip,pins =
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index d6e8b63daa42..d0cdc5f74212 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -23,6 +23,7 @@ aliases {
i2c0 = &i2c0;
i2c2 = &i2c2;
i2c3 = &i2c3;
+ i2c5 = &i2c5;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
@@ -400,6 +401,20 @@ i2c3: i2c@ff520000 {
status = "disabled";
};
+ i2c5: i2c@ff540000 {
+ compatible = "rockchip,rv1126-i2c", "rockchip,rk3399-i2c";
+ reg = <0xff540000 0x1000>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5m0_xfer>;
+ rockchip,grf = <&pmugrf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
pwm8: pwm@ff550000 {
compatible = "rockchip,rv1126-pwm", "rockchip,rk3328-pwm";
reg = <0xff550000 0x10>;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-07-06 9:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Andrew Lunn, Heiner Kallweit, Russell King
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-0-ff3176ca362b@gmail.com>
The board consists of a CLRV1126F core module and a DLRV1126 carrier
board. The core module contains the RV1126 SoC, eMMC and RK809 PMIC,
while the carrier board provides Ethernet, SD card, AP6212 WiFi and
Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and audio connectors.
The board has been tested with Ethernet/NFS boot, eMMC, SD card, SDIO
WiFi enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and
RK809 audio card registration.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 256 +++++++++++++++++++
3 files changed, 534 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/Makefile b/arch/arm/boot/dts/rockchip/Makefile
index d0154fd7ff24..e9f9e0ac3bfd 100644
--- a/arch/arm/boot/dts/rockchip/Makefile
+++ b/arch/arm/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
rv1109-relfor-saib.dtb \
rv1109-sonoff-ihost.dtb \
+ rv1126-alientek-dlrv1126.dtb \
rv1126-edgeble-neu2-io.dtb \
rv1126-sonoff-ihost.dtb \
rk3036-evb.dtb \
diff --git a/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi b/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi
new file mode 100644
index 000000000000..9bee424b1797
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Yanan He <grumpycat921013@gmail.com>
+ */
+
+#include "rv1126.dtsi"
+
+/ {
+ compatible = "alientek,clrv1126f", "rockchip,rv1126";
+
+ aliases {
+ mmc0 = &emmc;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&emmc {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_rstnout>;
+ rockchip,default-sample-phase = <90>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB1 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ #sound-dai-cells = <0>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+ clock-names = "mclk";
+ clocks = <&cru MCLK_I2S0_TX_OUT2IO>;
+ assigned-clocks = <&cru MCLK_I2S0_TX_OUT2IO>;
+ assigned-clock-parents = <&cru MCLK_I2S0_TX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc_buck5>;
+ vcc6-supply = <&vcc_buck5>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+
+ regulators {
+ vdd_npu_vepu: DCDC_REG1 {
+ regulator-name = "vdd_npu_vepu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_arm: DCDC_REG2 {
+ regulator-name = "vdd_arm";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc3v3_sys: DCDC_REG4 {
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_buck5: DCDC_REG5 {
+ regulator-name = "vcc_buck5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <2200000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2200000>;
+ };
+ };
+
+ vcc_0v8: LDO_REG1 {
+ regulator-name = "vcc_0v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmu: LDO_REG2 {
+ regulator-name = "vcc1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd0v8_pmu: LDO_REG3 {
+ regulator-name = "vcc0v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <800000>;
+ };
+ };
+
+ vcc_1v8: LDO_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_dovdd: LDO_REG5 {
+ regulator-name = "vcc_dovdd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_dvdd: LDO_REG6 {
+ regulator-name = "vcc_dvdd";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_avdd: LDO_REG7 {
+ regulator-name = "vcc_avdd";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG8 {
+ regulator-name = "vccio_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: LDO_REG9 {
+ regulator-name = "vcc3v3_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_5v0: SWITCH_REG1 {
+ regulator-name = "vcc_5v0";
+ };
+
+ vcc_3v3: SWITCH_REG2 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio0-supply = <&vcc3v3_sys>;
+ pmuio1-supply = <&vcc3v3_sys>;
+ vccio1-supply = <&vcc_1v8>;
+ vccio2-supply = <&vccio_sd>;
+ vccio3-supply = <&vcc_1v8>;
+ vccio4-supply = <&vcc_3v3>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_3v3>;
+ vccio7-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts b/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts
new file mode 100644
index 000000000000..33c6c74d08b9
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Yanan He <grumpycat921013@gmail.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include "rv1126-alientek-clrv1126f.dtsi"
+
+/ {
+ model = "Alientek ATK-DLRV1126";
+ compatible = "alientek,dlrv1126", "alientek,clrv1126f", "rockchip,rv1126";
+
+ aliases {
+ ethernet0 = &gmac;
+ mmc1 = &sdio;
+ mmc2 = &sdmmc;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-esc {
+ label = "esc";
+ linux,code = <KEY_ESC>;
+ press-threshold-microvolt = <0>;
+ };
+
+ button-right {
+ label = "right";
+ linux,code = <KEY_RIGHT>;
+ press-threshold-microvolt = <400781>;
+ };
+
+ button-left {
+ label = "left";
+ linux,code = <KEY_LEFT>;
+ press-threshold-microvolt = <801562>;
+ };
+
+ button-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ press-threshold-microvolt = <1198828>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "sys-led";
+ gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ led-1 {
+ label = "user-led";
+ gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ default-state = "on";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "Analog RK809";
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones",
+ "Microphone", "Mic Jack";
+ simple-audio-card,routing =
+ "Speaker", "SPKO",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR",
+ "MICL", "Mic Jack";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&rk809>;
+ };
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ sdio_pwrseq: pwrseq-sdio {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <200>;
+ power-off-delay-us = <20000>;
+ };
+};
+
+&i2c5 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PD0 IRQ_TYPE_LEVEL_LOW>;
+ clock-output-names = "xin32k";
+ };
+};
+
+&gmac {
+ phy-mode = "rgmii-id";
+ clock_in_out = "input";
+ assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
+ <&cru CLK_GMAC_ETHERNET_OUT>;
+ assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>,
+ <&cru RGMII_MODE_CLK>;
+ assigned-clock-rates = <125000000>, <0>, <25000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4
+ &clk_out_ethernetm1_pins>;
+ phy-handle = <&phy>;
+ status = "okay";
+};
+
+&mdio {
+ phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ clocks = <&cru CLK_GMAC_ETHERNET_OUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð_phy_rst>;
+ reset-gpios = <&gpio3 RK_PA0 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ };
+};
+
+&pinctrl {
+ ethernet {
+ eth_phy_rst: eth-phy-rst {
+ rockchip,pins = <3 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ bt {
+ bt_enable: bt-enable {
+ rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_dev: bt-wake-dev {
+ rockchip,pins = <1 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host: bt-wake-host {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sdio {
+ bus-width = <4>;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <25000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc1_clk &sdmmc1_cmd &sdmmc1_bus4>;
+ rockchip,default-sample-phase = <90>;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_bus4 &sdmmc0_det>;
+ rockchip,default-sample-phase = <90>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_ctsn &uart0_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43430a1-bt";
+ shutdown-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpio1 RK_PD1 GPIO_ACTIVE_HIGH>;
+ clocks = <&rk809 1>;
+ clock-names = "lpo";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA5 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "host-wakeup";
+ max-speed = <115200>;
+ vbat-supply = <&vcc_3v3>;
+ vddio-supply = <&vcc_1v8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_enable>, <&bt_wake_dev>, <&bt_wake_host>;
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&i2s0 {
+ rockchip,trcm-sync-tx-only;
+ rockchip,i2s-rx-route = <3 1 2 0>;
+ rockchip,i2s-tx-route = <0 1 2 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0m0_sclk_tx>,
+ <&i2s0m0_mclk>,
+ <&i2s0m0_lrck_tx>,
+ <&i2s0m0_sdo0>,
+ <&i2s0m0_sdo1_sdi3>;
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* RE: [PATCH net] tipc: fix NULL deref in tipc_named_node_up() on empty publication list
From: Tung Quang Nguyen @ 2026-07-06 9:21 UTC (permalink / raw)
To: Weiming Shi
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Xiang Mei, linux-kernel@vger.kernel.org, Jon Maloy,
netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net
In-Reply-To: <20260705115958.1066751-1-bestswngs@gmail.com>
>Subject: [PATCH net] tipc: fix NULL deref in tipc_named_node_up() on empty
>publication list
>
>named_distribute() builds the bulk messages for @pls into @list and then
>dereferences the tail skb:
>
> hdr = buf_msg(skb_peek_tail(list));
> msg_set_last_bulk(hdr);
>
>If @pls is empty no skb is enqueued, skb_peek_tail() returns NULL, and
>msg_set_last_bulk() writes through buf_msg(NULL).
>
>tipc_named_node_up() passes &nt->cluster_scope. With a node-id
>configuration the TIPC_NODE_STATE name is published by tipc_net_finalize()
>from a work item, which sets the node address before publishing the name.
>The node accepts links once the address is set, so a link that comes up before
>the publish runs named_distribute() on an empty cluster_scope:
>
> KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]
> RIP: 0010:tipc_named_node_up (net/tipc/name_distr.c:196)
> tipc_named_node_up (net/tipc/name_distr.c:196 net/tipc/name_distr.c:221)
> tipc_node_write_unlock (net/tipc/node.c:428)
> tipc_rcv (net/tipc/node.c:2185)
> tipc_udp_recv (net/tipc/udp_media.c:392) Kernel panic - not syncing: Fatal
>exception in interrupt
>
>TIPC genl ops use GENL_UNS_ADMIN_PERM, so an unprivileged user can reach
>this from a user+net namespace.
>
>Return early from named_distribute() when the list is empty, and skip
>tipc_node_xmit() for an empty chain. The empty chain would otherwise hit
>tipc_lxc_xmit() -> buf_msg(skb_peek(list)), the same zero-skb case fixed for
>tipc_link_xmit() in commit b77413446408 ("tipc: fix NULL deref in
>tipc_link_xmit()").
It needs to return earlier in tipc_named_node_up() like this:
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index ba4f4906e13b..60ccaa862162 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -218,6 +218,10 @@ void tipc_named_node_up(struct net *net, u32 dnode, u16 capabilities)
spin_unlock_bh(&tn->nametbl_lock);
read_lock_bh(&nt->cluster_scope_lock);
+ if (list_empty(&nt->cluster_scope)) {
+ read_unlock_bh(&nt->cluster_scope_lock);
+ return;
+ }
named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);
tipc_node_xmit(net, &head, dnode, 0);
read_unlock_bh(&nt->cluster_scope_lock);
>
>Fixes: cad2929dc432 ("tipc: update a binding service via broadcast")
>Reported-by: Xiang Mei <xmei5@asu.edu>
>Assisted-by: Claude:claude-opus-4-8
>Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>---
> net/tipc/name_distr.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
>diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c index
>ba4f4906e13b..c04fea4650a5 100644
>--- a/net/tipc/name_distr.c
>+++ b/net/tipc/name_distr.c
>@@ -192,7 +192,10 @@ static void named_distribute(struct net *net, struct
>sk_buff_head *list,
> skb_trim(skb, INT_H_SIZE + (msg_dsz - msg_rem));
> __skb_queue_tail(list, skb);
> }
>- hdr = buf_msg(skb_peek_tail(list));
>+ skb = skb_peek_tail(list);
>+ if (!skb)
>+ return;
>+ hdr = buf_msg(skb);
> msg_set_last_bulk(hdr);
> msg_set_named_seqno(hdr, seqno);
> }
>@@ -219,7 +222,8 @@ void tipc_named_node_up(struct net *net, u32 dnode,
>u16 capabilities)
>
> read_lock_bh(&nt->cluster_scope_lock);
> named_distribute(net, &head, dnode, &nt->cluster_scope, seqno);
>- tipc_node_xmit(net, &head, dnode, 0);
>+ if (!skb_queue_empty(&head))
>+ tipc_node_xmit(net, &head, dnode, 0);
> read_unlock_bh(&nt->cluster_scope_lock);
> }
>
>--
>2.43.0
>
^ permalink raw reply related
* [PATCH net] arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node
From: Meghana Malladi @ 2026-07-06 9:22 UTC (permalink / raw)
To: Vignesh Raghavendra, Nishanth Menon
Cc: s-anna, grygorii.strashko, conor+dt, krzk+dt, robh, kristo,
linux-arm-kernel, devicetree, linux-kernel, netdev, srk,
danishanwar, m-malladi
MDIO clock index changed from 62:3 to 81:0 to match proper clock
definition in the SoC device tree. Clock Id 81:0 belongs to ICSSG0
core clock, where as 62 belongs to EQEP2 device.
reference: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/clocks.html
Fixes: c9087e3898a1d0 ("arm64: dts: ti: k3-am64-main: Add ICSSG nodes")
Signed-off-by: Meghana Malladi <m-malladi@ti.com>
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 1b1d3970888b..a9a83781d40f 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -1401,7 +1401,7 @@ tx_pru0_1: txpru@c000 {
icssg0_mdio: mdio@32400 {
compatible = "ti,davinci_mdio";
reg = <0x32400 0x100>;
- clocks = <&k3_clks 62 3>;
+ clocks = <&k3_clks 81 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <0>;
base-commit: d7a8d500d7e42837bd8dce40cb52c97c6e8706a9
--
2.43.0
^ permalink raw reply related
* Re: [syzbot] Monthly virt report (Jun 2026)
From: Stefano Garzarella @ 2026-07-06 9:24 UTC (permalink / raw)
To: mawupeng
Cc: syzbot+listbf7b8eeeb8dda31d6de1, linux-kernel, syzkaller-bugs,
virtualization, mst, jasowang, xuanzhuo, eperezma, stefanha,
davem, edumazet, kuba, pabeni, horms, kvm, netdev
In-Reply-To: <d1e9d389-affa-4d12-aaf7-3fcf3218966c@huawei.com>
On Thu, 2 Jul 2026 at 04:55, mawupeng <mawupeng1@huawei.com> wrote:
> On 周四 2026-6-25 04:32, syzbot wrote:
> > Hello virt maintainers/developers,
> >
> > This is a 31-day syzbot report for the virt subsystem.
> > All related reports/information can be found at:
> > https://syzkaller.appspot.com/upstream/s/virt
> >
> > During the period, 0 new issues were detected and 0 were fixed.
> > In total, 5 issues are still open and 61 have already been fixed.
> > There are also 2 low-priority issues.
> >
> > Some of the still happening issues:
> >
> > Ref Crashes Repro Title
> > <1> 24 No WARNING: refcount bug in call_timer_fn (4)
> > https://syzkaller.appspot.com/bug?extid=07dcf509f4c013e25dc5
> > <2> 3 Yes memory leak in __vsock_create (2)
> > https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> Hi,
>
> This is regarding the still-open "memory leak in __vsock_create (2)"
> bug (#2 in the monthly virt report, extid 1b2c9c4a0f8708082678):
> https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
>
> I spent some time analyzing the root cause and the previous fix
> attempt; below is a summary and a direction that tested out.
[...]
>
> I'm not subscribed to follow the list at full volume; happy to send a
> formal patch (with the af_vsock.h / pending_work changes folded in)
> if the direction looks right to the maintainers.
Yes, please, a formal patch with a great commit message is much better
than a long text to read IMO.
Thanks,
Stefano
^ permalink raw reply
* [PATCH] ixgbe: validate E610 PFA TLV bounds
From: Pengpeng Hou @ 2026-07-06 9:25 UTC (permalink / raw)
To: Tony Nguyen
Cc: Pengpeng Hou, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
ixgbe_get_pfa_module_tlv() walks E610 PFA TLV records stored in
EEPROM.
Stop parsing malformed TLVs whose header or declared value length would
exceed the PFA boundary.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
index 4d8ae5b56145..03e88bdf5a43 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
@@ -3895,6 +3895,9 @@ static int ixgbe_get_pfa_module_tlv(struct ixgbe_hw *hw, u16 *module_tlv,
while (next_tlv < pfa_end_ptr) {
u16 tlv_sub_module_type, tlv_len;
+ if (pfa_end_ptr - next_tlv < 2)
+ break;
+
/* Read TLV type */
err = ixgbe_read_ee_aci_e610(hw, next_tlv,
&tlv_sub_module_type);
@@ -3917,6 +3920,9 @@ static int ixgbe_get_pfa_module_tlv(struct ixgbe_hw *hw, u16 *module_tlv,
/* Check next TLV, i.e. current TLV pointer + length + 2 words
* (for current TLV's type and length).
*/
+ if (tlv_len > pfa_end_ptr - next_tlv - 2)
+ break;
+
next_tlv = next_tlv + tlv_len + 2;
}
/* Module does not exist */
--
2.43.0
^ permalink raw reply related
* [PATCH] net: prestera: validate firmware header length
From: Pengpeng Hou @ 2026-07-06 9:26 UTC (permalink / raw)
To: Elad Nachman
Cc: Pengpeng Hou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
prestera_fw_hdr_parse() reads the firmware header before checking
that the firmware image contains that header.
Reject images shorter than struct prestera_fw_header before decoding the
magic and version fields.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/ethernet/marvell/prestera/prestera_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/marvell/prestera/prestera_pci.c b/drivers/net/ethernet/marvell/prestera/prestera_pci.c
index 2989a77e3b42..1ad0e62a8433 100644
--- a/drivers/net/ethernet/marvell/prestera/prestera_pci.c
+++ b/drivers/net/ethernet/marvell/prestera/prestera_pci.c
@@ -684,6 +684,9 @@ static int prestera_fw_hdr_parse(struct prestera_fw *fw)
struct prestera_fw_header *hdr;
u32 magic;
+ if (fw->bin->size < sizeof(*hdr))
+ return -EINVAL;
+
hdr = (struct prestera_fw_header *)fw->bin->data;
magic = be32_to_cpu(hdr->magic_number);
--
2.43.0
^ permalink raw reply related
* [PATCH v1 net-next] net: phy: Drop #inclusion of <linux/mod_devicetable.h> from <linux/mdio.h>
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-06 9:29 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit; +Cc: Russell King, netdev, linux-kernel
<linux/mdio.h> itself doesn't use any of the device id structures. The
files #including <linux/mdio.h> use a variety of them:
$ git grep -l '<linux/mdio.h>' | xargs grep --color -E '\<(acpi_device_id|amba_id|ap_device_id|apr_device_id|auxiliary_device_id|bcma_device_id|ccw_device_id|cdx_device_id|coreboot_device_id|css_device_id|dfl_device_id|dmi_(device|system)_id|eisa_device_id|fsl_mc_device_id|hda_device_id|hid_device_id|hv_vmbus_device_id|i2c_device_id|i3c_device_id|ieee1394_device_id|input_device_id|ipack_device_id|isapnp_device_id|ishtp_device_id|mcb_device_id|mdio_device_id|mei_cl_device_id|mhi_device_id|mips_cdmm_device_id|of_device_id|parisc_device_id|pci_device_id|pci_epf_device_id|pcmcia_device_id|platform_device_id|pnp_(card_)?device_id|rio_device_id|rpmsg_device_id|sdio_device_id|sdw_device_id|serio_device_id|slim_device_id|spi_device_id|spmi_device_id|ssam_device_id|ssb_device_id|tb_service_id|tee_client_device_id|typec_device_id|ulpi_device_id|usb_device_id|vchiq_device_id|virtio_device_id|wmi_device_id|x86_(cpu|device)_id|zorro_device_id|cpu_feature)\>'
...
but none of them relies on <linux/mdio.h>'s #include.
<linux/mod_devicetable.h> is a bad header mixing many different device
id structures and thus is an unfortunate dependency because if e.g.
struct wmi_device_id is modified all users of <linux/mdio.h> need to be
recompiled despite none of them using struct wmi_device_id.
So drop the unused header.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
the check that <linux/mod_devicetable.h> wasn't needed by all the users
of <linux/mdio.h> was done on top of v7.2-rc2.
Best regards
Uwe
include/linux/mdio.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index f4f9d9609448..300805e66592 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -8,7 +8,6 @@
#include <uapi/linux/mdio.h>
#include <linux/bitfield.h>
-#include <linux/mod_devicetable.h>
struct gpio_desc;
struct mii_bus;
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Sebastian Andrzej Siewior @ 2026-07-06 9:29 UTC (permalink / raw)
To: Qingfang Deng
Cc: Breno Leitao, Norbert Szetei, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Taegu Ha, Kees Cook,
linux-ppp, linux-kernel, Guillaume Nault, netdev,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, linux-modules
In-Reply-To: <87111f02-5b7a-4185-8364-2faba650578b@linux.dev>
+ MODULE maintainer
On 2026-07-05 10:57:44 [+0800], Qingfang Deng wrote:
> On 7/4/2026 at 12:32 AM, Breno Leitao wrote:
> > On Fri, Jul 03, 2026 at 03:27:00PM +0800, Qingfang Deng wrote:
> > > AI-review found an issue: https://sashiko.dev/#/patchset/D9C0245B-608B-4884-8A09-F55BA4A9F948%40doyensec.com
> > >
> > > An rcu_barrier() call is needed at the end of ppp_cleanup().
> >
> > I was initially unclear why rcu_barrier() would be necessary on a kfree path,
> > but it appears to be required during module unload to ensure that
> > ppp_release_channel_free() completes before the module's struct rcu_head is
> > destroyed. Is that the correct understanding?
>
> It's required to ensure that all ppp_release_channel_free() callback
> complete before the text segment of the module is unloaded.
So either a rcu_barrier() in ppp's module_exit() callback or a
synchronize_rcu() instead of the call_rcu(). And all this because the
module RCU callbacks pending which can be invoked after the module has
been removed. There is a synchronize_rcu() during module exit but this
is after the module code is gone.
I'm curious how many modules have a call_rcu() within their code but
don't have anything to enforce its completion before module removal is
complete? Wouldn't something like
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 46dd8d25a6058..8eae1ea2d6eb4 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -858,6 +858,9 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
goto out;
mutex_unlock(&module_mutex);
+
+ /* Ensure all rcu callbacks issued by the module have completed */
+ rcu_barrier();
/* Final destruction now no one is using it. */
if (mod->exit != NULL)
mod->exit();
make sense?
Sebastian
^ permalink raw reply related
* Re: [PATCH net-next v6 2/5] dpll: add DPLL_PIN_TYPE_INT_NCO pin type
From: Paolo Abeni @ 2026-07-06 9:31 UTC (permalink / raw)
To: Ivan Vecera, netdev, Vadim Fedorenko
Cc: Jiri Pirko, David S. Miller, Donald Hunter, Eric Dumazet,
Jakub Kicinski, Jiri Pirko, Michal Schmidt, Pasi Vaananen,
Arkadiusz Kubalewski, Petr Oros, Prathosh Satish, Simon Horman,
linux-kernel
In-Reply-To: <20260630125536.720717-3-ivecera@redhat.com>
On 6/30/26 2:55 PM, Ivan Vecera wrote:
> Add DPLL_PIN_TYPE_INT_NCO pin type for virtual pins representing
> the NCO mode of a DPLL. When connected as a DPLL input, the DPLL
> enters NCO mode where the output frequency is adjusted by the host
> via the PTP clock interface.
>
> Update the fractional-frequency-offset and fractional-frequency-
> offset-ppt attribute documentation to note that for INT_NCO pins
> these attributes represent the DPLL's current output frequency
> offset from its nominal frequency.
>
> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
@Vadim: it's not clear to me if your doubts over the design choice
raised in previous iterations are still there. My understanding is there
is reasonable agreement vs the new pin type, if you have very strong
objections please raise them soonish.
Thanks,
Paolo
^ permalink raw reply
* [PATCH net-next v5 2/2] net: lan743x: add support for RMII interface
From: Thangaraj Samynathan @ 2026-07-06 9:31 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
bryan.whitehead, UNGLinuxDriver, linux-kernel
In-Reply-To: <20260706093150.9033-1-thangaraj.s@microchip.com>
Enable RMII interface in the lan743x driver for PHY and MAC
configuration.
- Select RMII interface in lan743x_phy_interface_select().
- Update phylink supported_interfaces and MAC capabilities.
- Enable RMII via RMII_CTL in lan743x_hardware_init().
- Define RMII_CTL register and enable bit in lan743x_main.h.
EEE is not supported with RMII on PCI11x1x: the hardware does not
implement LPI signaling over RMII. Clear RMII from lpi_interfaces to
prevent phylink from enabling EEE on this interface.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
---
drivers/net/ethernet/microchip/lan743x_main.c | 23 +++++++++++++++++--
drivers/net/ethernet/microchip/lan743x_main.h | 3 +++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 3a418105cd11..24ae56a3c9ed 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1402,6 +1402,8 @@ static void lan743x_phy_interface_select(struct lan743x_adapter *adapter)
if (adapter->is_pci11x1x && adapter->is_sgmii_en)
adapter->phy_interface = PHY_INTERFACE_MODE_SGMII;
+ else if (adapter->is_pci11x1x && adapter->is_rmii_en)
+ adapter->phy_interface = PHY_INTERFACE_MODE_RMII;
else if (id_rev == ID_REV_ID_LAN7430_)
adapter->phy_interface = PHY_INTERFACE_MODE_GMII;
else if ((id_rev == ID_REV_ID_LAN7431_) && (data & MAC_CR_MII_EN_))
@@ -3190,6 +3192,12 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
__set_bit(PHY_INTERFACE_MODE_MII,
adapter->phylink_config.supported_interfaces);
break;
+ case PHY_INTERFACE_MODE_RMII:
+ __set_bit(PHY_INTERFACE_MODE_RMII,
+ adapter->phylink_config.supported_interfaces);
+ adapter->phylink_config.lpi_capabilities = 0;
+ break;
+
default:
phy_interface_set_rgmii(adapter->phylink_config.supported_interfaces);
}
@@ -3197,6 +3205,9 @@ static int lan743x_phylink_create(struct lan743x_adapter *adapter)
memcpy(adapter->phylink_config.lpi_interfaces,
adapter->phylink_config.supported_interfaces,
sizeof(adapter->phylink_config.lpi_interfaces));
+ if (adapter->phy_interface == PHY_INTERFACE_MODE_RMII)
+ __clear_bit(PHY_INTERFACE_MODE_RMII,
+ adapter->phylink_config.lpi_interfaces);
pl = phylink_create(&adapter->phylink_config, NULL,
adapter->phy_interface, &lan743x_phylink_mac_ops);
@@ -3541,6 +3552,7 @@ static int lan743x_hardware_init(struct lan743x_adapter *adapter,
{
struct lan743x_tx *tx;
u32 sgmii_ctl;
+ u32 rmii_ctl;
int index;
int ret;
@@ -3562,6 +3574,12 @@ static int lan743x_hardware_init(struct lan743x_adapter *adapter,
sgmii_ctl |= SGMII_CTL_SGMII_POWER_DN_;
}
lan743x_csr_write(adapter, SGMII_CTL, sgmii_ctl);
+ rmii_ctl = lan743x_csr_read(adapter, RMII_CTL);
+ if (adapter->is_rmii_en)
+ rmii_ctl |= RMII_CTL_RMII_ENABLE_;
+ else
+ rmii_ctl &= ~RMII_CTL_RMII_ENABLE_;
+ lan743x_csr_write(adapter, RMII_CTL, rmii_ctl);
} else {
adapter->max_tx_channels = LAN743X_MAX_TX_CHANNELS;
adapter->used_tx_channels = LAN743X_USED_TX_CHANNELS;
@@ -3628,8 +3646,9 @@ static int lan743x_mdiobus_init(struct lan743x_adapter *adapter)
adapter->mdiobus->name = "lan743x-mdiobus-c45";
dev_dbg(&adapter->pdev->dev, "lan743x-mdiobus-c45\n");
} else {
- dev_dbg(&adapter->pdev->dev, "RGMII operation\n");
- // Only C22 support when RGMII I/F
+ dev_dbg(&adapter->pdev->dev, "%s operation\n",
+ adapter->is_rmii_en ? "RMII" : "RGMII");
+ // Only C22 support when RGMII/RMII I/F
adapter->mdiobus->read = lan743x_mdiobus_read_c22;
adapter->mdiobus->write = lan743x_mdiobus_write_c22;
adapter->mdiobus->name = "lan743x-mdiobus";
diff --git a/drivers/net/ethernet/microchip/lan743x_main.h b/drivers/net/ethernet/microchip/lan743x_main.h
index 1f8d9294a6ef..d9495cf96b41 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.h
+++ b/drivers/net/ethernet/microchip/lan743x_main.h
@@ -325,6 +325,9 @@
#define MAC_WUCSR2_IPV6_TCPSYN_RCD_ BIT(5)
#define MAC_WUCSR2_IPV4_TCPSYN_RCD_ BIT(4)
+#define RMII_CTL (0x710)
+#define RMII_CTL_RMII_ENABLE_ BIT(0)
+
#define SGMII_ACC (0x720)
#define SGMII_ACC_SGMII_BZY_ BIT(31)
#define SGMII_ACC_SGMII_WR_ BIT(30)
--
2.34.1
^ permalink raw reply related
* [PATCH net-next v5 0/2] net: lan743x: add RMII support for PCI11x1x
From: Thangaraj Samynathan @ 2026-07-06 9:31 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
bryan.whitehead, UNGLinuxDriver, linux-kernel
This series adds RMII interface support for the Microchip PCI11x1x
Ethernet controller.
The PCI11x1x device supports RMII as an alternative MAC-PHY interface,
selected via the STRAP_READ software strap register. Patch 1 reads the
RMII strap bits from this register and sets the is_rmii_en flag. Patch 2
uses this flag to configure the PHY interface mode, phylink supported
interfaces, and enables RMII in hardware via the RMII_CTL register.
Change Log:
===========
v4 -> v5:
- Always write RMII_CTL with explicit set/clear of RMII_ENABLE_,
mirroring the SGMII_CTL pattern for a known register state on every
probe [Simon Horman, Paolo Abeni]
v3 -> v4:
- Fix dev_dbg() in lan743x_mdiobus_init() to print "RMII operation"
instead of "RGMII operation" when RMII is selected [Simon Horman]
v2 -> v3:
- Update debug log to report selected interface (SGMII/RMII/RGMII)
instead of only SGMII enable/disable state [patch 1/2]
- Update commit message to document that EEE is disabled by setting
lpi_capabilities = 0 [patch 2/2]
v1 -> v2:
- Remove redundant mac_capabilities &= ~MAC_1000FD; phylink already
handles capability reduction for RMII via phy_caps_from_interface()
[patch 2/2]
Thangaraj Samynathan (2):
net: lan743x: add RMII strap status detection for PCI11x1x
net: lan743x: add support for RMII interface
drivers/net/ethernet/microchip/lan743x_main.c | 35 ++++++++++++++++---
drivers/net/ethernet/microchip/lan743x_main.h | 6 ++++
2 files changed, 37 insertions(+), 4 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH net-next v5 1/2] net: lan743x: add RMII strap status detection for PCI11x1x
From: Thangaraj Samynathan @ 2026-07-06 9:31 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
bryan.whitehead, UNGLinuxDriver, linux-kernel
In-Reply-To: <20260706093150.9033-1-thangaraj.s@microchip.com>
Extend pci11x1x_strap_get_status() to read the RMII strap bits from
the STRAP_READ register. The is_rmii_en flag is initialized to
false and updated based on the hardware strap only if SGMII is not
already enabled. This ensures correct interface identification during
adapter initialization.
Update the netif_dbg() to report the selected interface as SGMII,
RMII, or RGMII.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
---
drivers/net/ethernet/microchip/lan743x_main.c | 12 ++++++++++--
drivers/net/ethernet/microchip/lan743x_main.h | 3 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index e759171bfd76..3a418105cd11 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -42,6 +42,7 @@ static void pci11x1x_strap_get_status(struct lan743x_adapter *adapter)
u32 strap;
int ret;
+ adapter->is_rmii_en = false;
/* Timeout = 100 (i.e. 1 sec (10 msce * 100)) */
ret = lan743x_hs_syslock_acquire(adapter, 100);
if (ret < 0) {
@@ -73,8 +74,15 @@ static void pci11x1x_strap_get_status(struct lan743x_adapter *adapter)
adapter->is_sgmii_en = false;
}
}
- netif_dbg(adapter, drv, adapter->netdev,
- "SGMII I/F %sable\n", adapter->is_sgmii_en ? "En" : "Dis");
+
+ if (!adapter->is_sgmii_en && strap & STRAP_READ_USE_RMII_EN_) {
+ if (strap & STRAP_READ_RMII_EN_)
+ adapter->is_rmii_en = true;
+ }
+
+ netif_dbg(adapter, drv, adapter->netdev, "Selected I/F: %s\n",
+ adapter->is_sgmii_en ? "SGMII" :
+ adapter->is_rmii_en ? "RMII" : "RGMII");
}
static bool is_pci11x1x_chip(struct lan743x_adapter *adapter)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.h b/drivers/net/ethernet/microchip/lan743x_main.h
index 1573c8f9c993..1f8d9294a6ef 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.h
+++ b/drivers/net/ethernet/microchip/lan743x_main.h
@@ -36,7 +36,9 @@
#define FPGA_SGMII_OP BIT(24)
#define STRAP_READ (0x0C)
+#define STRAP_READ_USE_RMII_EN_ BIT(23)
#define STRAP_READ_USE_SGMII_EN_ BIT(22)
+#define STRAP_READ_RMII_EN_ BIT(7)
#define STRAP_READ_SGMII_EN_ BIT(6)
#define STRAP_READ_SGMII_REFCLK_ BIT(5)
#define STRAP_READ_SGMII_2_5G_ BIT(4)
@@ -1072,6 +1074,7 @@ struct lan743x_adapter {
struct lan743x_rx rx[LAN743X_USED_RX_CHANNELS];
bool is_pci11x1x;
bool is_sgmii_en;
+ bool is_rmii_en;
/* protect ethernet syslock */
spinlock_t eth_syslock_spinlock;
bool eth_syslock_en;
--
2.34.1
^ permalink raw reply related
* [PATCH] net: bnx2x: validate firmware section bounds without overflow
From: Pengpeng Hou @ 2026-07-06 9:34 UTC (permalink / raw)
To: Sudarsana Kalluru
Cc: Pengpeng Hou, Manish Chopra, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
The firmware loader validates each section with offset + length before it
uses section offsets to read data from the firmware image. Both fields are
32-bit values from the firmware header, so the addition can wrap before it
is compared with the firmware size.
Validate sections as offset <= size and length <= size - offset instead.
Also require the firmware version section to contain the four bytes that
bnx2x_check_firmware() reads later.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 208a894d6190..c756a639e6ee 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13258,6 +13258,11 @@ static int bnx2x_init_dev(struct bnx2x *bp, struct pci_dev *pdev,
return rc;
}
+static bool bnx2x_fw_section_valid(size_t fw_size, u32 offset, u32 len)
+{
+ return offset <= fw_size && len <= fw_size - offset;
+}
+
static int bnx2x_check_firmware(struct bnx2x *bp)
{
const struct firmware *firmware = bp->firmware;
@@ -13281,7 +13286,7 @@ static int bnx2x_check_firmware(struct bnx2x *bp)
for (i = 0; i < sizeof(*fw_hdr) / sizeof(*sections); i++) {
offset = be32_to_cpu(sections[i].offset);
len = be32_to_cpu(sections[i].len);
- if (offset + len > firmware->size) {
+ if (!bnx2x_fw_section_valid(firmware->size, offset, len)) {
BNX2X_ERR("Section %d length is out of bounds\n", i);
return -EINVAL;
}
@@ -13300,6 +13305,11 @@ static int bnx2x_check_firmware(struct bnx2x *bp)
}
/* Check FW version */
+ if (be32_to_cpu(fw_hdr->fw_version.len) < 4) {
+ BNX2X_ERR("FW version section is too small\n");
+ return -EINVAL;
+ }
+
offset = be32_to_cpu(fw_hdr->fw_version.offset);
fw_ver = firmware->data + offset;
if (fw_ver[0] != bp->fw_major || fw_ver[1] != bp->fw_minor ||
--
2.43.0
^ permalink raw reply related
* [RFC net-next] pppoe: fix stale device name shown in procfs
From: Qingfang Deng @ 2026-07-06 9:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Qingfang Deng, Kees Cook, Felix Fietkau,
Eric Woudstra, netdev, linux-kernel
Cc: linux-ppp
In pppoe_seq_show(), the device name is currently read from
po->pppoe_pa.dev, which contains the name at the time the socket was
connected. If the lower network device is renamed afterwards, reading
/proc/net/pppoe will still print the old name.
Fix this by reading the name directly from the bound net_device via the
po->pppoe_dev pointer. Note that the pointer can be cleared when the
socket is being released, so a NULL check is required.
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
---
drivers/net/ppp/pppoe.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 4a018acb5262..5bf526c596b6 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -960,6 +960,7 @@ static int pppoe_recvmsg(struct socket *sock, struct msghdr *m,
#ifdef CONFIG_PROC_FS
static int pppoe_seq_show(struct seq_file *seq, void *v)
{
+ struct net_device *dev;
struct pppox_sock *po;
char *dev_name;
@@ -969,7 +970,10 @@ static int pppoe_seq_show(struct seq_file *seq, void *v)
}
po = v;
- dev_name = po->pppoe_pa.dev;
+ dev = READ_ONCE(po->pppoe_dev);
+ if (!dev)
+ goto out;
+ dev_name = dev->name;
seq_printf(seq, "%08X %pM %8s\n",
po->pppoe_pa.sid, po->pppoe_pa.remote, dev_name);
--
2.43.0
^ permalink raw reply related
* [PATCH] net: hinic: validate firmware image section bounds
From: Pengpeng Hou @ 2026-07-06 9:34 UTC (permalink / raw)
To: Cai Huoqing
Cc: Pengpeng Hou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
The firmware update path copies each section from the image with an offset
and length supplied by the firmware header. The image validator only
checked the sum of section lengths and used fw_len + header_size to check
the file size, but it did not prove that each section offset and length
fits in the firmware payload.
Reject images with a truncated header, avoid the fw_len plus header-size
addition, validate each section type before it is used as a bit index, and
prove every section range with offset <= fw_len and len <= fw_len - offset.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
.../net/ethernet/huawei/hinic/hinic_devlink.c | 57 ++++++++++++++++---
1 file changed, 49 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
index c977c43e5d5a..0c06fbdadad3 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
@@ -20,14 +20,25 @@
#include "hinic_devlink.h"
#include "hinic_hw_dev.h"
+static bool hinic_fw_section_valid(u32 fw_len, u32 offset, u32 len)
+{
+ return offset <= fw_len && len <= fw_len - offset;
+}
+
static bool check_image_valid(struct hinic_devlink_priv *priv, const u8 *buf,
- u32 image_size, struct host_image_st *host_image)
+ size_t image_size, struct host_image_st *host_image)
{
- struct fw_image_st *fw_image = NULL;
+ const struct fw_image_st *fw_image;
u32 len = 0;
u32 i;
- fw_image = (struct fw_image_st *)buf;
+ if (image_size < UPDATEFW_IMAGE_HEAD_SIZE) {
+ dev_err(&priv->hwdev->hwif->pdev->dev,
+ "Wrong image size read from file\n");
+ return false;
+ }
+
+ fw_image = (const struct fw_image_st *)buf;
if (fw_image->fw_magic != HINIC_MAGIC_NUM) {
dev_err(&priv->hwdev->hwif->pdev->dev, "Wrong fw_magic read from file, fw_magic: 0x%x\n",
@@ -41,14 +52,44 @@ static bool check_image_valid(struct hinic_devlink_priv *priv, const u8 *buf,
return false;
}
+ if (fw_image->fw_len != image_size - UPDATEFW_IMAGE_HEAD_SIZE) {
+ dev_err(&priv->hwdev->hwif->pdev->dev,
+ "Wrong data size read from file\n");
+ return false;
+ }
+
for (i = 0; i < fw_image->fw_info.fw_section_cnt; i++) {
- len += fw_image->fw_section_info[i].fw_section_len;
- host_image->image_section_info[i] = fw_image->fw_section_info[i];
+ const struct fw_section_info_st *section =
+ &fw_image->fw_section_info[i];
+
+ if (section->fw_section_type >= FILE_TYPE_TOTAL_NUM) {
+ dev_err(&priv->hwdev->hwif->pdev->dev,
+ "Wrong section type read from file: %u\n",
+ section->fw_section_type);
+ return false;
+ }
+
+ if (!hinic_fw_section_valid(fw_image->fw_len,
+ section->fw_section_offset,
+ section->fw_section_len)) {
+ dev_err(&priv->hwdev->hwif->pdev->dev,
+ "Wrong section size read from file\n");
+ return false;
+ }
+
+ if (section->fw_section_len > fw_image->fw_len - len) {
+ dev_err(&priv->hwdev->hwif->pdev->dev,
+ "Wrong data size read from file\n");
+ return false;
+ }
+
+ len += section->fw_section_len;
+ host_image->image_section_info[i] = *section;
}
- if (len != fw_image->fw_len ||
- (fw_image->fw_len + UPDATEFW_IMAGE_HEAD_SIZE) != image_size) {
- dev_err(&priv->hwdev->hwif->pdev->dev, "Wrong data size read from file\n");
+ if (len != fw_image->fw_len) {
+ dev_err(&priv->hwdev->hwif->pdev->dev,
+ "Wrong data size read from file\n");
return false;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: amd: seattle: Remove useless clocks DTSI include
From: Krzysztof Kozlowski @ 2026-07-06 9:35 UTC (permalink / raw)
To: Suravee Suthikulpanit, Tom Lendacky, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Raju Rangoju,
Prashanth Kumar K R, Richard Cochran, devicetree, linux-kernel,
netdev
Cc: Krzysztof Kozlowski
The "amd-seattle-clks.dtsi" file is included exactly once, so paste the
contents directly in proper DTSI. No functional impact.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi | 43 -------------------
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 36 +++++++++++++++-
2 files changed, 35 insertions(+), 44 deletions(-)
delete mode 100644 arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi
deleted file mode 100644
index 73f687773ce6..000000000000
--- a/arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * DTS file for AMD Seattle Clocks
- *
- * Copyright (C) 2014 Advanced Micro Devices, Inc.
- */
-
- adl3clk_100mhz: uartspiclk_100mhz: clock-100000000 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <100000000>;
- clock-output-names = "adl3clk_100mhz";
- };
-
- ccpclk_375mhz: clock-375000000 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <375000000>;
- clock-output-names = "ccpclk_375mhz";
- };
-
- sataclk_333mhz: clock-333000000 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <333000000>;
- clock-output-names = "sataclk_333mhz";
- };
-
- dmaclk_500mhz: pcieclk_500mhz: clock-500000000 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <500000000>;
- clock-output-names = "pcieclk_500mhz";
- };
-
- xgmacclk0_dma_250mhz: xgmacclk0_ptp_250mhz: xgmacclk1_dma_250mhz: xgmacclk1_ptp_250mhz:
- miscclk_250mhz: clock-250000000 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <250000000>;
- clock-output-names = "miscclk_250mhz";
- };
-
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a611f8288b3e..c5b9dbfdf014 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -11,7 +11,41 @@ / {
#address-cells = <2>;
#size-cells = <2>;
- /include/ "amd-seattle-clks.dtsi"
+ adl3clk_100mhz: uartspiclk_100mhz: clock-100000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "adl3clk_100mhz";
+ };
+
+ ccpclk_375mhz: clock-375000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <375000000>;
+ clock-output-names = "ccpclk_375mhz";
+ };
+
+ sataclk_333mhz: clock-333000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <333000000>;
+ clock-output-names = "sataclk_333mhz";
+ };
+
+ dmaclk_500mhz: pcieclk_500mhz: clock-500000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <500000000>;
+ clock-output-names = "pcieclk_500mhz";
+ };
+
+ xgmacclk0_dma_250mhz: xgmacclk0_ptp_250mhz: xgmacclk1_dma_250mhz: xgmacclk1_ptp_250mhz:
+ miscclk_250mhz: clock-250000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <250000000>;
+ clock-output-names = "miscclk_250mhz";
+ };
gic0: interrupt-controller@e1101000 {
compatible = "arm,gic-400", "arm,cortex-a15-gic";
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox