Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
References: <20230802161049.89326-1-dmantipov@yandex.ru>
        <169278633096.1133515.976396654998983133.kvalo@kernel.org>
        <CA+ASDXOTyRtMgNc47v=Qy28Y+grCh=xwL31qZM9YXVjkbwGC0Q@mail.gmail.com>
Date:   Fri, 25 Aug 2023 10:13:15 +0300
In-Reply-To: <CA+ASDXOTyRtMgNc47v=Qy28Y+grCh=xwL31qZM9YXVjkbwGC0Q@mail.gmail.com>
        (Brian Norris's message of "Wed, 23 Aug 2023 12:49:28 -0700")
Message-ID: <87jztjvblg.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Brian Norris <briannorris@chromium.org> writes:

> On Wed, Aug 23, 2023 at 3:25=E2=80=AFAM Kalle Valo <kvalo@kernel.org> wro=
te:
>>
>> 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.

--=20
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatc=
hes