linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: Kalle Valo <kvalo@kernel.org>,
	linux-wireless@vger.kernel.org, lvc-project@linuxtesting.org
Subject: Re: [PATCH 2/2] [v2] wifi: mwifiex: cleanup TX error handling
Date: Tue, 1 Aug 2023 10:55:22 -0700	[thread overview]
Message-ID: <ZMlHCmjf2ZovExsP@google.com> (raw)
In-Reply-To: <20230728084407.101930-2-dmantipov@yandex.ru>

On Fri, Jul 28, 2023 at 11:43:43AM +0300, Dmitry Antipov wrote:
> Since 'mwifiex_process_tx()' is the only place from where both
> 'mwifiex_process_sta_txpd()' and 'mwifiex_process_uap_txpd()'
> are called, these functions may be converted to 'void' after
> moving skb layout check to the caller, which may be simplified
> as well. Also adjust somewhat obfuscating error messages and
> add 'mwifiex_interface_name()' to make them a bit more useful.

Do you actually run this driver on anything, or are you just compile
testing / running static analysis? Because IIUC, all these messages are
perfectly clear when using the mwifiex_dbg() macro, which usually ends
up in dev_info(), and includes things like "mwifiex_pcie",
"mwifiex_sdio", and "mwifiex_usb" already. So the
mwifiex_interface_name() stuff just seems superfluous. I'd suggest
removing that.

At the same time, it seems like you're working hard on trying *not* to
get your stuff merged in a timely manner, as you shift the goalposts
every time you refactor your series. Specifically, you're now violating
basic guidelines like these:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_messages

"If you find yourself listing out a number of changes in the commit
message as a bulleted list or similar, consider splitting up the patch
into discrete changes that each do one thing. Similarly, if one of the
additional considerations is refactoring, try to shift that into a
separate patch."

This started out as "avoid BUG_ON()", which is a great goal on its own.
But now you haven't even mentioned that in your laundry list of
refactors. This seems like you have at least two patch candidates here:
refactoring the error handling, and dropping the BUG_ON(). (If the
refactoring becomes extremely trivial, maybe this is OK as 1 patch. But
in its current form, it's not.)

Before you resubmit, please read the patch submission guidelines again.
I'd also suggest sticking this (as multiple patches) at the end of the
series, so the other patches (which have been reviewed/ack'd multiple
times) can land cleanly.

Brian

> Suggested-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> v2: some redesign in attempt to integrate Brian's feedback
[...]

  reply	other threads:[~2023-08-01 17:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26  7:20 [PATCH 1/5] wifi: mwifiex: fix memory leak in mwifiex_histogram_read() Dmitry Antipov
2023-07-26  7:20 ` [PATCH 2/5] wifi: mwifiex: drop BUG_ON() from TX error handling Dmitry Antipov
2023-07-26 19:22   ` Brian Norris
2023-07-26  7:20 ` [PATCH 3/5] wifi: mwifiex: cleanup private data structures Dmitry Antipov
2023-07-26  7:20 ` [PATCH 4/5] wifi: mwifiex: handle possible sscanf() errors Dmitry Antipov
2023-07-26  7:20 ` [PATCH 5/5] wifi: mwifiex: handle possible mwifiex_write_reg() errors Dmitry Antipov
2023-07-26 19:24 ` [PATCH 1/5] wifi: mwifiex: fix memory leak in mwifiex_histogram_read() Brian Norris
2023-07-28  8:43   ` [PATCH 1/5] [v2] " Dmitry Antipov
2023-07-28  8:43     ` [PATCH 2/2] [v2] wifi: mwifiex: cleanup TX error handling Dmitry Antipov
2023-08-01 17:55       ` Brian Norris [this message]
2023-08-02 11:45         ` [lvc-project] " Antipov, Dmitriy
2023-08-02 16:07         ` [PATCH 1/5] [v3] wifi: mwifiex: fix memory leak in mwifiex_histogram_read() Dmitry Antipov
2023-08-02 16:07           ` [PATCH 2/5] [v3] wifi: mwifiex: cleanup private data structures Dmitry Antipov
2023-08-02 16:07           ` [PATCH 3/5] [v3] wifi: mwifiex: handle possible sscanf() errors Dmitry Antipov
2023-08-02 16:07           ` [PATCH 4/5] [v3] wifi: mwifiex: handle possible mwifiex_write_reg() errors Dmitry Antipov
2023-08-02 16:07           ` [PATCH 5/5] [v3] wifi: mwifiex: drop BUG_ON from TX paths Dmitry Antipov
2023-08-08 19:58             ` Brian Norris
2023-08-21 15:56           ` [PATCH 1/5] [v3] wifi: mwifiex: fix memory leak in mwifiex_histogram_read() Kalle Valo
2023-07-28  8:43     ` [PATCH 3/5] [v2] wifi: mwifiex: cleanup private data structures Dmitry Antipov
2023-07-28  8:43     ` [PATCH 4/5] [v2] wifi: mwifiex: handle possible sscanf() errors Dmitry Antipov
2023-07-28  8:43     ` [PATCH 5/5] [v2] wifi: mwifiex: handle possible mwifiex_write_reg() errors Dmitry Antipov
2023-07-31  9:46     ` [PATCH 1/5] [v2] wifi: mwifiex: fix memory leak in mwifiex_histogram_read() Kalle Valo
2023-07-31  9:55       ` [lvc-project] " Antipov, Dmitriy
2023-07-28  9:29   ` [lvc-project] [PATCH 1/5] " Antipov, Dmitriy
2023-07-31  9:47     ` Kalle Valo

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=ZMlHCmjf2ZovExsP@google.com \
    --to=briannorris@chromium.org \
    --cc=dmantipov@yandex.ru \
    --cc=kvalo@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lvc-project@linuxtesting.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).