On Tue, Feb 9, 2021 at 2:23 AM Kevin Hao <haoke...@gmail.com> wrote: > > Pavel pointed that the return of dma_addr_t in > otx2_alloc_rbuf/__otx2_alloc_rbuf() seem suspicious because a negative > error code may be returned in some cases. For a dma_addr_t, the error > code such as -ENOMEM does seem a valid value, so we can't judge if the > buffer allocation fail or not based on that value. Add a parameter for > otx2_alloc_rbuf/__otx2_alloc_rbuf() to store the dma address and make > the return value to indicate if the buffer allocation really fail or > not. > > Reported-by: Pavel Machek <pa...@ucw.cz> > Signed-off-by: Kevin Hao <haoke...@gmail.com> > Tested-by: Subbaraya Sundeep <sbha...@marvell.com>
Actually in most cases -ENOMEM wouldn't be a valid value. The issue is that you wouldn't have enough space to store anything since you are only 12 bytes from overflowing the DMA value. That is why ~0 is used as the DMA_MAPPING_ERROR value as there is only enough space to possibly store 1 byte before it overflows. I wonder if it wouldn't make sense to look at coming up with a set of macros to convert the error values into a dma_addr_t value and to test for those errors being present similar to what we already have for pointers. It should work for most cases as I think the error values are only up to something like -133 and I don't think we have too many cases where something like an Rx buffer will be that small. Anyway that is future work for another time. The code itself looks fine. Reviewed-by: Alexander Duyck <alexanderdu...@fb.com>
