Brian Norris <briannorris@xxxxxxxxxxxx> writes:
> On Wed, Aug 23, 2023 at 3:25 AM Kalle Valo <kvalo@xxxxxxxxxx> wrote:
>>
>> Dmitry Antipov <dmantipov@xxxxxxxxx> wrote:
>>
>> > Simplify PCIE DMA mapping management by eliminating extra copies
>> > of {address, size} pairs to/from temporary data structures. Map
>> > and unmap operations may use skb fields directly via introduced
>> > 'MWIFIEX_SKB_DMA_ADDR()' and 'MWIFIEX_SKB_DMA_SIZE()' macros.
>> >
>> > Signed-off-by: Dmitry Antipov <dmantipov@xxxxxxxxx>
>>
>> I assume these patches are compile tested only so I'm very reluctant
>> take these.
>>
>> 2 patches set to Changes Requested.
>
> That's fair IMO. These kinds of patches put a much larger burden on
> the reviewer to make sure they make sense. Thus, I had this in a
> backlog to review, and haven't gotten around to it.
I'm looking at this from risk vs reward point of view. The risk is that
these cause regressions which is of course more work for us maintainers
but I'm not really seeing any concrete benefit from these patches.
> [1] Although, I don't think I have permission to change the Patchwork
> status, so it still might be lost to /dev/null without a RESEND.
I can change the status by request, not a problem. We could also setup
you admin access to patchwork.
BTW with ath9k patches we do so that patchwork first assigns the patches
automatically to Toke. Once Toke has reviewed the patches he either
drops of them or assigns them for me so I can commit them. At least from
my point of view that works really well, do let me know if you would
like to try something like that.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
