mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Jeff Chen <jeff.chen_1@nxp.com>, linux-wireless@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, briannorris@chromium.org,
	 francesco@dolcini.it, tsung-hsien.hsieh@nxp.com,
	s.hauer@pengutronix.de,  brian.hsu@nxp.com
Subject: Re: [PATCH v5 18/22] wifi: nxpwifi: add core files
Date: Thu, 04 Sep 2025 13:37:20 +0200	[thread overview]
Message-ID: <6b8ff5139bb9c361468840046b757dfa5ebe1aba.camel@sipsolutions.net> (raw)
In-Reply-To: <20250804154018.3563834-19-jeff.chen_1@nxp.com>

On Mon, 2025-08-04 at 23:40 +0800, Jeff Chen wrote:
> 
> +/* The main process.
> + *
> + * This function is the main procedure of the driver and handles various driver
> + * operations. It runs in a loop and provides the core functionalities.
> + *
> + * The main responsibilities of this function are -
> + *      - Ensure concurrency control
> + *      - Handle pending interrupts and call interrupt handlers
> + *      - Wake up the card if required
> + *      - Handle command responses and call response handlers
> + *      - Handle events and call event handlers
> + *      - Execute pending commands
> + *      - Transmit pending data packets
> + */
> +void nxpwifi_main_process(struct nxpwifi_adapter *adapter)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&adapter->main_proc_lock, flags);
> +
> +	/* Check if already processing */
> +	if (adapter->nxpwifi_processing || adapter->main_locked) {
> +		adapter->more_task_flag = true;
> +		spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> +		return;
> +	}
> +
> +	adapter->nxpwifi_processing = true;
> +	spin_unlock_irqrestore(&adapter->main_proc_lock, flags);


This makes me very nervous, it at least means it's super hard to
understand when this may or may not be running ... It's also the sort of
custom locking that's kind of frowned upon.

Could this not be with wiphy mutex and be very clear? Though maybe you
wouldn't want TX to go through that ... and maybe it can't since sdio
calls it? But that seems odd, why is it both a worker and called for
every interrupt? Should it even be a single function for those two
cases?

Also it sets more_task_flag when it's entered while already running, but
that's just weird? Should other work coming in really get processed by
the SDIO interrupt processing?

It seems to me this is one of those awful design things inherited by
mwifiex that just happens to work? Can you document it well? If so maybe
do that and that can say why it really needs to be this way. If not, you
should probably change it completely and redesign it from first
principles, i.e. figure out what it has to do and build it accordingly?

The whole function is also everything and the kitchen sink, could use
some serious refactoring?

> +		if (adapter->delay_null_pkt && !adapter->cmd_sent &&
> +		    !adapter->curr_cmd && !is_command_pending(adapter) &&
> +		    (nxpwifi_wmm_lists_empty(adapter) &&
> +		     nxpwifi_bypass_txlist_empty(adapter) &&
> +		     skb_queue_empty(&adapter->tx_data_q))) {
> +			if (!nxpwifi_send_null_packet
> +			    (nxpwifi_get_priv(adapter, NXPWIFI_BSS_ROLE_STA),
> +			     NXPWIFI_TxPD_POWER_MGMT_NULL_PACKET |
> +			     NXPWIFI_TxPD_POWER_MGMT_LAST_PACKET)) {
> +				adapter->delay_null_pkt = false;
> +				adapter->ps_state = PS_STATE_SLEEP;
> +			}
> +			break;
> +		}
> +	} while (true);


Sao that ... those conditions are awful? If this were a separate
function at least you could write it in multiple lines with return
true/false there.

> +/* CFG802.11

(side note: there's really no such thing as "CFG802.11" FWIW, it was
always just called "cfg80211")

johannes

  reply	other threads:[~2025-09-04 11:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-04 15:39 [PATCH v5 00/22] wifi: nxpwifi: create nxpwifi to support iw61x Jeff Chen
2025-08-04 15:39 ` [PATCH v5 01/22] wifi: nxpwifi: add 802.11n files Jeff Chen
2025-09-04 11:22   ` Johannes Berg
2025-08-04 15:39 ` [PATCH v5 02/22] wifi: nxpwifi: add 802.11ac files Jeff Chen
2025-08-04 15:39 ` [PATCH v5 03/22] wifi: nxpwifi: add 802.11ax files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 04/22] wifi: nxpwifi: add 802.11h file Jeff Chen
2025-08-04 15:40 ` [PATCH v5 05/22] wifi: nxpwifi: add WMM files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 06/22] wifi: nxpwifi: add scan.c Jeff Chen
2025-08-04 15:40 ` [PATCH v5 07/22] wifi: nxpwifi: add join.c Jeff Chen
2025-08-04 15:40 ` [PATCH v5 08/22] wifi: nxpwifi: add cfp.c Jeff Chen
2025-08-04 15:40 ` [PATCH v5 09/22] wifi: nxpwifi: add configuration files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 10/22] wifi: nxpwifi: implement cfg80211 ops Jeff Chen
2025-08-04 15:40 ` [PATCH v5 11/22] wifi: nxpwifi: add host command file Jeff Chen
2025-08-04 15:40 ` [PATCH v5 12/22] wifi: nxpwifi: add command and event files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 13/22] wifi: nxpwifi: add data path files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 14/22] wifi: nxpwifi: add debugfs file Jeff Chen
2025-08-04 15:40 ` [PATCH v5 15/22] wifi: nxpwifi: add ethtool.c Jeff Chen
2025-08-04 15:40 ` [PATCH v5 16/22] wifi: nxpwifi: add utility files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 17/22] wifi: nxpwifi: add initialization file Jeff Chen
2025-08-04 15:40 ` [PATCH v5 18/22] wifi: nxpwifi: add core files Jeff Chen
2025-09-04 11:37   ` Johannes Berg [this message]
2025-09-19 18:06     ` Jeff Chen
2025-10-01 10:17       ` Jeff Chen
2025-10-01 10:19         ` Johannes Berg
2025-08-04 15:40 ` [PATCH v5 19/22] wifi: nxpwifi: add sdio bus driver files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 20/22] wifi: nxpwifi: modify sdio_ids.h Jeff Chen
2025-08-04 15:40 ` [PATCH v5 21/22] wifi: nxpwifi: add makefile and kconfig files Jeff Chen
2025-08-04 15:40 ` [PATCH v5 22/22] wifi: nxpwifi: modify MAINTAINERS file Jeff Chen
2025-09-04 11:39 ` [PATCH v5 00/22] wifi: nxpwifi: create nxpwifi to support iw61x Johannes Berg
2025-10-07 16:49 ` Martyn Welch
2025-10-09 16:01   ` Jeff Chen
2025-10-10 16:22     ` Martyn Welch
2025-10-13 18:18       ` [EXT] " Jeff Chen
2025-10-14 10:20         ` Martyn Welch

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=6b8ff5139bb9c361468840046b757dfa5ebe1aba.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=brian.hsu@nxp.com \
    --cc=briannorris@chromium.org \
    --cc=francesco@dolcini.it \
    --cc=jeff.chen_1@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=tsung-hsien.hsieh@nxp.com \
    /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

all inboxes | Powered by JetHome®