Re: [PATCH net] net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG
Simon Horman <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Aug 11, 2026 at 10:38:55AM +0530, Siddharth Vadapalli wrote: > On 10/08/26 22:26, Simon Horman wrote: > > 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://netdev-ai.bots.linux.dev/sashiko/#/patchset/[email protected]?part=1 > > --- > > --- Patch [1]: [PATCH net] net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG --- > > commit b0ed959d350c90d8b49f6f81eba7461fbc86dcf4 > > Author: Siddharth Vadapalli <[email protected]> > > > > net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG > > > > The RX path extracts the ingress MAC port ID from the CPPI5 descriptor's > > 16-bit Source Tag. Only the lower 8 bits carry the port ID, so the patch > > masks the value with 0xFF before it is used as an index into > > common->ports[]. > > > > > diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c > > > index 434a31080855..6330540979d7 100644 > > > --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c > > > +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c > > > @@ -1310,6 +1310,8 @@ static int am65_cpsw_nuss_rx_packets(struct am65_cpsw_rx_flow *flow, > > > k3_udma_glue_rx_cppi5_to_dma_addr(rx_chn->rx_chn, &buf_dma); > > > pkt_len = cppi5_hdesc_get_pktlen(desc_rx); > > > cppi5_desc_get_tags_ids(&desc_rx->hdr, &port_id, NULL); > > > + /* Port ID is contained in the lower 8-bits of the 16-bit Source Tag */ > > > + port_id &= 0xFF; > > > dev_dbg(dev, "%s rx port_id:%d\n", __func__, port_id); > > > port = am65_common_get_port(common, port_id); > > > ndev = port->ndev; > > > > [Severity: High] > > [Finding: main-1-0] > > [Sources: opus-5] > > > > The missing range check on port_id is pre-existing and not introduced by > > this patch, but since the change is specifically about avoiding the > > out-of-bounds access, would it be worth validating the value instead of > > relying only on the mask? > > Hardware guarantees a valid Port ID in the lower 8-bits. A Software check is > an unnecessary overhead and will impact performance since this is on the > data-path and is not a one-time check during initialization. ... Hi Siddharth, Thanks for addressing the AI generated review. This all looks good to me now. Reviewed-by: Simon Horman <[email protected]>