From: Kalle Valo <kvalo@kernel.org>
To: Pkshih <pkshih@realtek.com>
Cc: "linux-wireless\@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 13/19] rtw89: extend role_maintain to support AP mode
Date: Thu, 03 Feb 2022 10:42:59 +0200 [thread overview]
Message-ID: <877daccpd8.fsf@kernel.org> (raw)
In-Reply-To: <97e80d86f5b925a0b2337d15c56e88d3808b6efe.camel@realtek.com> (Pkshih's message of "Sat, 29 Jan 2022 03:36:14 +0000")
Pkshih <pkshih@realtek.com> writes:
> On Fri, 2022-01-28 at 17:51 +0200, Kalle Valo wrote:
>> Ping-Ke Shih <pkshih@realtek.com> writes:
>>
>> > Fill mac_id and self_role depends on the operation mode.
>> >
>> > In AP mode, echo connected station has an unique mac_id, and each vif also
>> > has one mac_id to represent itself.
>> >
>> > The self_role is assigned to vif if the operation mode is decided, and
>> > RTW89_SELF_ROLE_AP_CLIENT is assigned to the connected STA in AP mode,
>> >
>> > Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
>> > ---
>> > drivers/net/wireless/realtek/rtw89/fw.c | 8 ++++++--
>> > drivers/net/wireless/realtek/rtw89/fw.h | 1 +
>> > drivers/net/wireless/realtek/rtw89/mac.c | 4 ++--
>> > 3 files changed, 9 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/net/wireless/realtek/rtw89/fw.c b/drivers/net/wireless/realtek/rtw89/fw.c
>> > index 5209813275676..4641aadea0386 100644
>> > --- a/drivers/net/wireless/realtek/rtw89/fw.c
>> > +++ b/drivers/net/wireless/realtek/rtw89/fw.c
>> > @@ -993,9 +993,13 @@ int rtw89_fw_h2c_update_beacon(struct rtw89_dev *rtwdev,
>> > #define H2C_ROLE_MAINTAIN_LEN 4
>> > int rtw89_fw_h2c_role_maintain(struct rtw89_dev *rtwdev,
>> > struct rtw89_vif *rtwvif,
>> > + struct rtw89_sta *rtwsta,
>> > enum rtw89_upd_mode upd_mode)
>> > {
>> > struct sk_buff *skb;
>> > + u8 mac_id = rtwsta ? rtwsta->mac_id : rtwvif->mac_id;
>> > + u8 self_role = rtwvif->net_type == RTW89_NET_TYPE_AP_MODE && rtwsta ?
>> > + RTW89_SELF_ROLE_AP_CLIENT : rtwvif->self_role;
>>
>> It seems you like '?' operator more than I do, and it's ok to use in
>> simple cases. But the latter statement is not really readable, something
>> like this is so much easier to read:
>>
>> if (rtwvif->net_type == RTW89_NET_TYPE_AP_MODE && rtwsta)
>> self_role = RTW89_SELF_ROLE_AP_CLIENT
>> else
>> self_role = rtwvif->self_role;
>>
>
> I use '?' to make code shorter, but your sugeestion would be eaiser to reviewer.
> I will send v2 after the Lunar New Year.
Happy New Year :)
>> But should there a parenthesis around the == operator? I cannot now
>> recall what's the preference in the kernel, can someone help on that?
>
> The checkpatch will warn this if we add parenthesis, so preence is not to
> use parenthesis.
>
> CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'rtwvif->net_type ==
> RTW89_NET_TYPE_AP_MODE'
> #9: FILE: fw.c:1004:
> + if ((rtwvif->net_type == RTW89_NET_TYPE_AP_MODE) && rtwsta)
Ok, I need to remember that :)
>> Maybe I also move check for rtwsta first?
>>
>
> The full logic is
>
> if (rtwvif->net_type == RTW89_NET_TYPE_AP_MODE) {
> if (rtwsta)
> self_role = RTW89_SELF_ROLE_AP_CLIENT
> else
> self_role = rtwvif->self_role;
> } else {
> self_role = rtwvif->self_role;
> }
>
> And, the meaning of 'rtwsta' here is to indicate we are going to setup
> a connected station that connects to this AP, but not check if the
> pointer is NULL. To emphasis the case is only existing in AP_MODE,
> I prefer to check net_type ahead. Or, this full logic is preferred?
I don't know what others think, but I find this full logic style most
readable.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2022-02-03 8:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 3:42 [PATCH 00/19] rtw89: support AP mode Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 01/19] rtw89: configure rx_filter according to FIF_PROBE_REQ Ping-Ke Shih
2022-01-28 15:57 ` Kalle Valo
2022-01-07 3:42 ` [PATCH 02/19] rtw89: use hardware SSN to TX management frame Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 03/19] rtw89: download beacon content to firmware Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 04/19] rtw89: add C2H handle of BCN_CNT Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 05/19] rtw89: implement mac80211_ops::set_tim to indicate STA to receive packets Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 06/19] rtw89: allocate mac_id for each station in AP mode Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 07/19] rtw89: extend firmware commands on states of sta_assoc and sta_disconnect Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 08/19] rtw89: rename vif_maintain to role_maintain Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 09/19] rtw89: configure mac port HIQ registers Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 10/19] rtw89: send broadcast/multicast packets via HIQ if STAs are in sleep mode Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 11/19] rtw89: set mac_id and port ID to TXWD Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 12/19] rtw89: separate {init,deinit}_addr_cam functions Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 13/19] rtw89: extend role_maintain to support AP mode Ping-Ke Shih
2022-01-28 15:51 ` Kalle Valo
2022-01-29 3:36 ` Pkshih
2022-02-03 8:42 ` Kalle Valo [this message]
2022-02-03 9:41 ` Pkshih
2022-01-28 15:53 ` Kalle Valo
2022-01-07 3:42 ` [PATCH 14/19] rtw89: add addr_cam field to sta " Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 15/19] rtw89: only STA mode change vif_type mapping dynamically Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 16/19] rtw89: maintain assoc/disassoc STA states of firmware and hardware Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 17/19] rtw89: implement ieee80211_ops::start_ap and stop_ap Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 18/19] rtw89: debug: add stations entry to show ID assignment Ping-Ke Shih
2022-01-07 3:42 ` [PATCH 19/19] rtw89: declare AP mode support 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=877daccpd8.fsf@kernel.org \
--to=kvalo@kernel.org \
--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).