On Fri, Jul 10, 2026 at 11:59:02AM +0100, Peter Maydell wrote: > In omap_dma_transfer_setup(), the maximum number of elements we can > transfer is 0xffff * 0xffff == 0xfffe0001 (because the max frame > count and max elements per frame are both 65535). However, we store > total element counts in 'int' variables, and use INT_MAX as a "bigger > than any valid value" sentinel, and when performing arithmetic with > the total count of transferred elements we are not careful about > avoiding overflows. Fix these: > > - use uint32_t rather than int for the local variables tracking > various element and frame counts > - use UINT_MAX as our sentinel > - calculate new packet, element and frame counter values using > arithmetic on a local uint32_t, rather than doing it in-place > on local variables that are only 'int' because the actual > counter registers are 16 bits > - use 64-bit arithmetic when calculating how much to advance the > source and dest pointers and the total dma->bytes transferred > > Note that since soc_dma_ch_s::bytes is only 'int' this can still > overflow; we'll fix that in a subsequent patch. > > Signed-off-by: Peter Maydell <[email protected]>
LGTM, thanks Peter. Reviewed-by: Jim MacArthur <[email protected]>
