All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Pkshih <pkshih@realtek.com>, Arnd Bergmann <arnd@arndb.de>
Cc: "linux-wireless\@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v6 03/24] rtw89: add core and trx files
Date: Tue, 05 Oct 2021 10:46:26 +0300	[thread overview]
Message-ID: <87pmsjgbhp.fsf@codeaurora.org> (raw)
In-Reply-To: <4b2f1c6b06e040d19b64d07500e0447b@realtek.com> (Pkshih's message of "Tue, 5 Oct 2021 07:16:44 +0000")

Pkshih <pkshih@realtek.com> writes:

>> -----Original Message-----
>> From: kvalo=codeaurora.org@mg.codeaurora.org
>> <kvalo=codeaurora.org@mg.codeaurora.org> On
>> Behalf Of Kalle Valo
>> Sent: Saturday, October 2, 2021 12:26 AM
>> To: Pkshih <pkshih@realtek.com>
>> Cc: linux-wireless@vger.kernel.org
>> Subject: Re: [PATCH v6 03/24] rtw89: add core and trx files
>> 
>> Ping-Ke Shih <pkshih@realtek.com> writes:
>> 
>> > Implement main flows that contains register/unregister mac80211 hw with
>> > hardware capability, power on/off sequence, STA state actions, and
>> > TX/RX path.
>> >
>> > The chip info is read from efuse while probing PCI, and then it can be
>> > used to induce supported channel, band, bitrate, ht/vht/he capability,
>> > and etc. Then, we register hardware with these capabilities.
>> >
>> > When network interface is up, driver does power-on sequence to enable MAC,
>> > BB and RF function blocks. Oppositely, do power-off sequence when
>> > interface is going to down.
>> >
>> > To maintain STA state, five callbacks are implemented -- add, assoc,
>> > disassoc, disconnect and remove. In which state, driver tells firmware STA
>> > info via H2C.
>> >
>> > TX flow:
>> > When a SKB is going to be transmitted, we must know its type first. If
>> > the type is mgmt or fwcmd made by driver, SKB is queued into corresponding
>> > DMA channel and PCI ring. The other type is data frame that is more
>> > complex, because it needs to establish BA session to have better throughput
>> > with AMPDU and AMSDU.
>> > In order to have better PCI DMA efficiency, we don't kick off DMA every
>> > SKB. With wake TX queue, kick off DMA after a bunch of SKBs are written.
>> > To achieve this, we have two HCI ops -- tx_write and tx_kick_off.
>> >
>> > BA establishment work:
>> > For data frames, we start to establish BA session if the STA is associated
>> > with APMDU capability and the TID session isn't established, and then the
>> > BA work is used to ask mac80211 to start AMPDU actions. Driver implements
>> > AMPDU action callbacks to know the session is established, so that we can
>> > set AGG_EN bit in TX descriptor to enable AMPDU.
>> >
>> > RX flow:
>> > When a RX SKB is delivered from PCI, rtw89_core_rx() process it depneds on
>> > its type -- WIFI, C2H or PPDU. If type is C2H, it's queued into a C2H
>> > queue, and wake a work to handle the C2H packet. If type is WIFI, it's a
>> > normal RX packet. When mgmt or data frame is received, it is queued
>> > into pending RX SKB queue to wait for corresponding PPDU packet (another
>> > RX packet with PPDU type) to fill its rx_status, like RSSI. And, then
>> > indicate this packet to mac80211. When control frame is received, indicate
>> > it to mac80211 immediately.
>> >
>> > Track work:
>> > Use track work to monitor PHY status to know the changes of environment,
>> > and then update RA status or do RFK accordingly.
>> >
>> > Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
>> 
>> [...]
>> 
>> > +static __always_inline void RTW89_SET_TXWD(u8 *txdesc, u32 val,
>> > u8 offset, u32 mask)
>> > +{
>> > +	u32 *txd32 = (u32 *)txdesc;
>> > +
>> > +	le32p_replace_bits((__le32 *)(txd32 + offset), val, mask);
>> > +}
>> 
>> I'm not convinced about this either, please just use inline.
>
> This is because 'mask' argument of le32p_replace_bits() must be constant
> only. If I use inline and build this driver with ccflags-y += -Os,
> compiler reports errors:
>
> In function 'field_multiplier',
>     inlined from 'le32_encode_bits' at ./include/linux/bitfield.h:154:1,
>     inlined from 'le32p_replace_bits' at ./include/linux/bitfield.h:154:1,
>     inlined from 'RTW89_SET_FWCMD_UA32.constprop' at /work/git-root/rtwlan/rtw89/fw.h:1397:2:
> ./include/linux/bitfield.h:119:3: error: call to '__bad_mask' declared with attribute error: bad bitfield mask
>   119 |   __bad_mask();
>       |   ^~~~~~~~~~~~
>
> I check the implement of le32p_replace_bits(), it looks like
>
> static __always_inline void type##p_replace_bits(__##type *p,           \
>                                         base val, base field)           \
> {                                                                       \
>         *p = (*p & ~to(field)) | type##_encode_bits(val, field);        \
> }
>
> So, I imitate the function to use __always_inline, and then it works.
>
> Do you think I don't need to consider the case of Os?
> But, -Os seems a standard option of Linux kernel.
>
> ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
> KBUILD_CFLAGS += -O2
> else ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3
> KBUILD_CFLAGS += -O3
> else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> KBUILD_CFLAGS += -Os
> endif

Yeah, we need to support -Os.

Arnd, what do you suggest? Is __always_inline good solution for this? I
think we should at least add a comment explaining why it's needed.

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

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

  reply	other threads:[~2021-10-05  7:46 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20  4:35 [PATCH v6 00/24] rtw89: add Realtek 802.11ax driver Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 01/24] rtw89: add CAM files Ping-Ke Shih
2021-10-01 14:46   ` Kalle Valo
2021-08-20  4:35 ` [PATCH v6 02/24] rtw89: add BT coexistence files Ping-Ke Shih
2021-10-01 15:26   ` Kalle Valo
2021-10-01 17:40     ` Small driver submissions and long feedback cycles Brian Norris
2021-08-20  4:35 ` [PATCH v6 03/24] rtw89: add core and trx files Ping-Ke Shih
2021-10-01 16:26   ` Kalle Valo
2021-10-05  7:16     ` Pkshih
2021-10-05  7:46       ` Kalle Valo [this message]
2021-10-05  8:42         ` Arnd Bergmann
2021-10-05  9:32           ` Pkshih
2021-10-05  9:59             ` Arnd Bergmann
2021-10-06  1:35               ` Pkshih
2021-10-06  7:32                 ` Arnd Bergmann
2021-10-06  8:19                   ` Pkshih
2021-08-20  4:35 ` [PATCH v6 04/24] rtw89: add debug files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 05/24] rtw89: add efuse files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 06/24] rtw89: add files to download and communicate with firmware Ping-Ke Shih
2021-10-01 15:55   ` Kalle Valo
2021-08-20  4:35 ` [PATCH v6 07/24] rtw89: add MAC files Ping-Ke Shih
2021-10-01 16:13   ` Kalle Valo
2021-08-20  4:35 ` [PATCH v6 08/24] rtw89: implement mac80211 ops Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 09/24] rtw89: add pci files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 10/24] rtw89: add phy files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 11/24] rtw89: define register names Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 12/24] rtw89: add regulatory support Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 13/24] rtw89: 8852a: add 8852a specific files Ping-Ke Shih
2021-10-01 16:20   ` Kalle Valo
2021-08-20  4:35 ` [PATCH v6 14/24] rtw89: 8852a: add 8852a RFK files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 15/24] rtw89: 8852a: add 8852a RFK tables Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 16/24] rtw89: 8852a: add 8852a tables (1 of 5) Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 17/24] rtw89: 8852a: add 8852a tables (2 " Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 18/24] rtw89: 8852a: add 8852a tables (3 " Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 19/24] rtw89: 8852a: add 8852a tables (4 " Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 20/24] rtw89: 8852a: add 8852a tables (5 " Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 21/24] rtw89: add ser to recover error reported by firmware Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 22/24] rtw89: add PS files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 23/24] rtw89: add SAR files Ping-Ke Shih
2021-08-20  4:35 ` [PATCH v6 24/24] rtw89: add Kconfig and Makefile Ping-Ke Shih
2021-08-22  3:43   ` kernel test robot
2021-08-23  1:37     ` Pkshih
2021-10-01 15:57   ` Kalle Valo
2021-10-01 16:34 ` [PATCH v6 00/24] rtw89: add Realtek 802.11ax driver Kalle Valo
2021-10-01 16:42   ` Larry Finger
2021-10-01 16:46     ` Kalle Valo
2021-10-01 17:18       ` Larry Finger
2021-10-05  5:46         ` Kalle Valo
2021-10-04  6:46   ` Pkshih
2021-10-05  5:52     ` Kalle Valo
2021-10-06  0:10       ` Brian Norris
2021-10-08  4:14         ` Pkshih
2021-10-08  4:11       ` Pkshih
2021-10-09  8:28         ` Kalle Valo
2021-10-12  1:53           ` Pkshih

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=87pmsjgbhp.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=arnd@arndb.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --subject='Re: [PATCH v6 03/24] rtw89: add core and trx files' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.