From: Kalle Valo <kvalo@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: Dmitry Antipov <dmantipov@yandex.ru>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/2] wifi: mwifiex: simplify PCIE DMA mapping management
Date: Fri, 25 Aug 2023 10:13:15 +0300 [thread overview]
Message-ID: <87jztjvblg.fsf@kernel.org> (raw)
In-Reply-To: <CA+ASDXOTyRtMgNc47v=Qy28Y+grCh=xwL31qZM9YXVjkbwGC0Q@mail.gmail.com> (Brian Norris's message of "Wed, 23 Aug 2023 12:49:28 -0700")
Brian Norris <briannorris@chromium.org> writes:
> On Wed, Aug 23, 2023 at 3:25 AM Kalle Valo <kvalo@kernel.org> wrote:
>>
>> Dmitry Antipov <dmantipov@yandex.ru> 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@yandex.ru>
>>
>> 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
prev parent reply other threads:[~2023-08-25 7:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 16:09 [PATCH 1/2] wifi: mwifiex: simplify PCIE DMA mapping management Dmitry Antipov
2023-08-02 16:09 ` [PATCH 2/2] wifi: mwifiex: avoid indirection in PCIE buffer descriptor management Dmitry Antipov
2023-08-23 10:25 ` [PATCH 1/2] wifi: mwifiex: simplify PCIE DMA mapping management Kalle Valo
2023-08-23 19:49 ` Brian Norris
2023-08-25 7:13 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jztjvblg.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=briannorris@chromium.org \
--cc=dmantipov@yandex.ru \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).