> child_device_obj->device cannot perform DMA properly if dma_set_mask()
> returns non-zero. …
Can the repetition of another wording suggestion influence the software
evolution?
Direct memory access can not be properly performed any more
after a dma_set_mask() call failed.
See also:
https:/
> child_device_obj->device cannot perform DMA properly if dma_set_mask()
> returns non-zero. …
Another wording suggestion:
Direct memory access can not be properly performed any more
after a dma_set_mask() call failed.
See also:
https://elixir.bootlin.com/linux/v6.10-rc6/source/kernel/dma/ma
…
> Eliminate the duplication by making minor tweaks to the logic and
> associated comments. While here, simplify the handling of memory
> allocation errors, and use umin() instead of open coding it.
…
I got the impression that the adjustment for the mentioned macro
should be performed in a separa
> It occurred to me overnight that the existing error handling
> in create_gpadl_header() is unnecessarily complicated. Here's
> an approach that I think would fix what you have flagged, and
> would reduce complexity instead of increasing it. Thoughts?
I find this development view interesting.
>> The kfree() function was called in two cases by
>> the create_gpadl_header() function during error handling
>> even if the passed variable contained a null pointer.
>> This issue was detected by using the Coccinelle software.
>>
>> Thus use another label.
>
> Interestingly, there's a third case
From: Markus Elfring
Date: Tue, 26 Dec 2023 20:00:24 +0100
The kfree() function was called in two cases by
the create_gpadl_header() function during error handling
even if the passed variable contained a null pointer.
This issue was detected by using the Coccinelle software.
Thus use another
