Hi Luo Jie, netdev,

I'm porting the GL.iNet GL-BE9300 (IPQ5332) to mainline OpenWrt and have run
into what looks like a gap in qcom_ppe for a direct (non-DSA) MAC port. The
question is at the bottom; I'm happy to provide the full DT, register dumps, or
test patches.

Setup
-----
SoC: IPQ5332, kernel 6.12, drivers/net/ethernet/qualcomm/ppe. Two ports:

- port@1: 10G SerDes, DSA conduit to an external RTL8372N switch (eth0). RX
works fine; the DSA tagger demuxes the switch ports.
- port@2: 2.5G, direct on-board RTL8221B PHY (phy-mode = "2500base-x"), used as
a standalone L3 "WAN" (eth1, no bridge, no DSA). RX is broken.

Symptom (port@2)
----------------
Link comes up at 2.5G/full. The MAC receives - the PPE ingress counters
advance:

PORT_RX_CNT ... 4/1(port=0002)
VPORT_RX_CNT ... 4/0(port=0002)

...but eth1 rx_packets stays 0, and the EDMA RX-ring error stat shows the drop:

/sys/kernel/debug/ppe/edma/stats/rx_ring_stats:
rxdesc[15]:src_port_inval_type = 1

So the frame reaches the EDMA RX descriptor ring, but in edma_rx_get_src_dev()
the source is not tagged as PORTID:

if ((src_info & EDMA_RXDESC_SRCINFO_TYPE_MASK) ==
EDMA_RXDESC_SRCINFO_TYPE_PORTID) {
src_port_num = src_info & EDMA_RXDESC_PORTNUM_BITS;
...
} else {
... ++rxdesc_stats->src_port_inval_type; /* port@2: type == 0 */
return NULL; /* dropped */
}

so the netdev lookup never runs.

What I have checked
-------------------
- netdev_arr[port_id - 1] is populated for port@2 (edma_port_setup), so the
PORTID -> netdev mapping would resolve if the type were PORTID.
- port@2's L2 forwarding is the fallback path: PPE_L2_VP_PORT_TBL with
INVALID_VSI_FWD_EN = 1, DST_INFO = 0 (CPU port0) - set for every physical
port in ppe_config.c. That controls the destination; the RX descriptor
src_info type is still 0.
- Bridging eth1 (to give it a VSI) does not change it.
- port@1 (the DSA conduit) gets SRCINFO_TYPE_PORTID and is delivered correctly,
so the tagging clearly happens for that port's path.

Question
--------
What configures a port so the PPE tags its host-bound frames with
SRCINFO_TYPE_PORTID + src_port? Is there a per-port setup (an EG service code,
a source-port profile, a physical-vs-virtual-port distinction) that the
DSA-conduit path establishes but a standalone direct MAC port does not?

And more generally: is "deliver a direct MAC port's own ingress to the host
CPU" (a plain WAN/L3 port - no DSA, no bridge offload) an intended/supported
configuration today, or does the EDMA RX path assume all host-bound traffic
arrives via the DSA conduit or an offloaded bridge VSI?

Thanks,
Kamil Bienkiewicz (perceival on the OpenWrt forum)