linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: <kevin_yang@realtek.com>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 3/6] wifi: rtw89: introduce helpers to wait/complete on condition
Date: Mon, 28 Nov 2022 15:29:05 +0200	[thread overview]
Message-ID: <87sfi35hsu.fsf@kernel.org> (raw)
In-Reply-To: <20221118051042.29968-4-pkshih@realtek.com> (Ping-Ke Shih's message of "Fri, 18 Nov 2022 13:10:39 +0800")

Ping-Ke Shih <pkshih@realtek.com> writes:

> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> MCC (multi-channel concurrency) related H2Cs require to wait for C2H
> responses to judge the execution result and data. We introduce helpers
> to assist this process. Besides, we would like the helpers to be generic
> for use in driver even outside of MCC H2C/C2H, so we make a independent
> patch for them.
>
> In the following, I describe the things first.
> ```
> (A)	C2H is generated by FW, and then transferred upto driver. Hence,
> 	driver cannot get it immediately without a bit waitting/blocking.
> 	For this, we choose to use wait_for_completion_*() instead of
> 	busy polling.
> (B)	From the driver management perspective, a scenario, e.g. MCC,
> 	may have mulitple kind of H2C functions requiring this process
> 	to wait for corresponding C2Hs. But, the driver management flow
> 	uses mutex to protect each behavior. So, one scenario triggers
> 	one H2C function at one time. To avoid rampant instances of
> 	struct completion for each H2C function, we choose to use one
> 	struct completion with one condition flag for one scenario.
> (C)	C2Hs, which H2Cs will be waitting for, cannot be ordered with
> 	driver management flow, i.e. cannot enqueue work to the same
> 	ordered workqueue and cannot lock by the same mutex, to prevent
> 	H2C side from getting no C2H responses. So, those C2Hs are parsed
> 	in interrupt context directly as done in previous commit.
> (D)	Following (C), the above underline H2Cs and C2Hs will be handled
> 	in different contexts without sync. So, we use atomic_cmpxchg()
> 	to compare and change the condition in atomic.
> ```
>
> So, we introduce struct rtw89_wait_info which combines struct completion
> and atomic_t. Then, the below are the descriptions for helper functions.
> * rtw89_wait_for_cond() to wait for a completion based on a condition.
> * rtw89_complete_cond() to complete a given condition and carry data.
> Each rtw89_wait_info instance independently determines the meaning of
> its waitting conditions. But, RTW89_WAIT_COND_IDLE (UINT_MAX) is reserved.
>
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>

Just nitpicking a couple of items:

Otherwise an excellent commit log but the meaning of C2H and H2C is not
clear for me. I guess they mean "chip to host" and "host to chip", but
would be good to clarify that in the beginning.

> --- a/drivers/net/wireless/realtek/rtw89/core.h
> +++ b/drivers/net/wireless/realtek/rtw89/core.h
> @@ -2802,6 +2802,34 @@ struct rtw89_mac_info {
>  	u8 cpwm_seq_num;
>  };
>  
> +struct rtw89_completion_data {
> +	bool err;
> +#define RTW89_COMPLETION_BUF_SIZE 24
> +	u8 buf[RTW89_COMPLETION_BUF_SIZE];
> +};

Having a define withing a struct looks odd to me, I would prefer to have
it outside of the struct.

> +#define rtw89_completion_cast(cmpl_data, ptr)				\
> +({									\
> +	typecheck(struct rtw89_completion_data *, cmpl_data);		\
> +	BUILD_BUG_ON(sizeof(*(ptr)) > RTW89_COMPLETION_BUF_SIZE);	\
> +	(typeof(ptr))(cmpl_data)->buf;					\
> +})

Wouldn't this be cleaner as a static inline function?

> +struct rtw89_wait_info {
> +#define RTW89_WAIT_COND_IDLE UINT_MAX
> +	atomic_t cond;
> +	struct completion completion;
> +	struct rtw89_completion_data data;
> +};

Also here would prefer the define outside the struct.

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

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

  reply	other threads:[~2022-11-28 13:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18  5:10 [PATCH 0/6] wifi: rtw89: preparation of MCC Ping-Ke Shih
2022-11-18  5:10 ` [PATCH 1/6] wifi: rtw89: rfk: rename rtw89_mcc_info to rtw89_rfk_mcc_info Ping-Ke Shih
2022-11-18  5:10 ` [PATCH 2/6] wifi: rtw89: check if atomic before queuing c2h Ping-Ke Shih
2022-11-18  5:10 ` [PATCH 3/6] wifi: rtw89: introduce helpers to wait/complete on condition Ping-Ke Shih
2022-11-28 13:29   ` Kalle Valo [this message]
2022-11-29  4:18     ` Ping-Ke Shih
2022-11-18  5:10 ` [PATCH 4/6] wifi: rtw89: mac: process MCC related C2H Ping-Ke Shih
2022-11-28 13:30   ` Kalle Valo
2022-11-29  0:22     ` Ping-Ke Shih
2022-11-29  5:35       ` Kalle Valo
2022-11-18  5:10 ` [PATCH 5/6] wifi: rtw89: fw: implement MCC related H2C Ping-Ke Shih
2022-11-18  5:10 ` [PATCH 6/6] wifi: rtw89: link rtw89_vif and chanctx stuffs Ping-Ke Shih

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=87sfi35hsu.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=kevin_yang@realtek.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.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;
as well as URLs for NNTP newsgroup(s).