hw/dma/omap_dma: Be more careful about overflow in transfer setup

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 <peter.maydell@linaro.org> Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org> Message-id: 20260710105907.2570621-5-peter.maydell@linaro.org