Re: [PATCH v2 net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Hardware data buffers for Stream Gate Control List (sgcl_data) and Stream Filter Counters (sfi_counter_data) use native u32 fields without cpu_to_le32() / le32_to_cpu() conversions.
--

commit e19bf50d7194e9cfc29fbcd1560a65dbc9d0f7a0
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation

Replace the open-coded struct_size() + kzalloc() pattern with the
kzalloc_flex() helper when allocating struct enetc_psfp_gate. This
removes the intermediate entries_size local variable and makes the
allocation site more concise.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
> index 7b17bca24f260..2aa0fcaafcd23 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
[ ... ]
> @@ -1242,8 +1241,7 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
>  		goto free_filter;
>  	}
>  
> -	entries_size = struct_size(sgi, entries, entryg->gate.num_entries);
> -	sgi = kzalloc(entries_size, GFP_KERNEL);
> +	sgi = kzalloc_flex(*sgi, entries, entryg->gate.num_entries);

[Severity: High]
This isn't a bug introduced by this patch, but does the hardware data buffer
for the Stream Gate Control List (sgcl_data) and Stream Filter Counters
(sfi_counter_data) need cpu_to_le32() / le32_to_cpu() conversions?

In enetc_streamgate_hw_set(), native u32 values are written into the
sgcl_data structure without endianness conversion:

    sgcl_data->ct = sgi->cycletime;
    sgcl_data->cte = sgi->cycletimext;

and later for the entries:

    to->interval = from->interval;

Similarly, in enetc_streamcounter_hw_get(), native u32 values are read from
the sfi_counter_data structure:

    cnt->matching_frames_count = ((u64)data_buf->matchh << 32) +
                                 data_buf->matchl;

Since these structures are mapped to hardware via coherent DMA memory, will
this cause the hardware to receive incorrect configuration values and software
to read corrupted QoS statistics on Big Endian architectures?

>  	if (!sgi) {
>  		err = -ENOMEM;
>  		goto free_filter;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702025714.456233-1-wei.fang@oss.nxp.com?part=14