From: Ping-Ke Shih <pkshih@realtek.com>
To: Luka Gejak <luka.gejak@linux.dev>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Michael Straube" <straube.linux@gmail.com>,
Peter Robinson <pbrobinson@gmail.com>,
Bitterblue Smith <rtl8821cerfe2@gmail.com>
Subject: RE: [PATCH v3 3/6] wifi: rtw88: 8723b: add the RTL8723B chip driver
Date: Wed, 23 Sep 2026 08:30:57 +0000 [thread overview]
Message-ID: <39da13e5cdd840f5a5ab86ded478d07c@realtek.com> (raw)
In-Reply-To: <20260921154347.82317-4-luka.gejak@linux.dev>
Luka Gejak <luka.gejak@linux.dev> wrote:
> Add the Realtek RTL8723B 802.11n chip driver: the chip operations, the
> power sequences, the efuse layout, the RF and IQ calibration, and the
> chip specific coexistence handling.
>
> This depends on the shared core handling sent as a separate series,
> "wifi: rtw88: preparations for RTL8723B/RTL8723BS". The driver is not
> built yet; the Kconfig and Makefile entries follow.
No need this paragraph.
>
> The RTL8723B chip support is based on the initial work by
> Michael Straube <straube.linux@gmail.com>.
> Link: https://github.com/mistraube/rtw88/tree/rtl8723bs
>
> Co-developed-by: Michael Straube <straube.linux@gmail.com>
> Signed-off-by: Michael Straube <straube.linux@gmail.com>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
> drivers/net/wireless/realtek/rtw88/rtw8723b.c | 2938 +++++++++++++++++
As LOC is large, I think I can't address all flaws in single one review
iteration. Please also review patches yourself before sending out.
I think you're quite experienced now.
> drivers/net/wireless/realtek/rtw88/rtw8723b.h | 12 +
> 2 files changed, 2950 insertions(+)
> create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8723b.c
> create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8723b.h
>
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723b.c
> b/drivers/net/wireless/realtek/rtw88/rtw8723b.c
> new file mode 100644
> index 000000000000..9e53ba49def3
> --- /dev/null
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8723b.c
> @@ -0,0 +1,2938 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Copyright(c) 2007-2017 Realtek Corporation
> + * Copyright(c) Michael Straube <straube.linux@gmail.com>
> + * Copyright(c) 2024-2026 Luka Gejak <luka.gejak@linux.dev>
> + */
> +
> +#include <linux/unaligned.h>
> +#include "main.h"
> +#include "coex.h"
> +#include "fw.h"
> +#include "mac.h"
> +#include "phy.h"
> +/*
> + * Shares the receive PHY status layout, the SDIO aggregation burst fields
> + * and a few baseband registers with the RTL8703B; reuse that header.
> + */
> +#include "rtw8703b.h"
> +#include "rtw8723b.h"
> +#include "rtw8723b_table.h"
> +#include "sdio.h"
> +#include "tx.h"
In increasing alphabet order.
[...]
> +/* 0x03a05611 is the normal RX path (staging and the BB table agree);
> + * 0x03a05600 is only an IQK temporary value and must not be reasserted.
> + */
Keep first line of block comment blank.
> +#define WLAN_RX_PATH_A_8723B 0x03a05611
> +
> +#define ADDA_ON_VAL_8723B 0x01c00014
> +
> +#define MASK_NETTYPE 0x30000
> +#define _NETTYPE(x) (((x) & 0x3) << 16)
> +#define NT_LINK_AP 0x2
The PORT_SET_NET_TYPE in rtw_vif_port_config() does similar thing
relying on ``` static const struct rtw_vif_port rtw_vif_port[]```.
Is that not suitable for RTL8723B? If so, should the common flow
avoid RTL8723B?
> +
> +#define WLAN_RX_FILTER0 0xFFFF
> +#define WLAN_RX_FILTER1 0x400
> +#define WLAN_RX_FILTER2 0xFFFF
> +/* Keep BIT_APP_FCS: rtw88 advertises RX_INCLUDES_FCS for every chip, and
> + * without it mac80211 trims four bytes of real frame data.
> + */
Please review block comment style. (I'd not point out this afterward)
[...]
> +
> +static const struct rtw_pwr_seq_cmd trans_pre_enable_8723b[] = {
> + /* unlock ISO/CLK/power control register */
> + {REG_RSV_CTRL,
> + RTW_PWR_CUT_ALL_MSK,
> + RTW_PWR_INTF_ALL_MSK,
> + RTW_PWR_ADDR_MAC,
> + RTW_PWR_CMD_WRITE, 0xff, 0},
> +
Not prefer the blank line. (apply this rule to tables below)
> + {TRANS_SEQ_END},
> +};
> +
[...]
> +
> +static void rtw8723b_efuse_grant(struct rtw_dev *rtwdev, bool on)
> +{
> + /*
> + * This chip wraps the common efuse power switch in a BT power cut
> + * (0x6A[14] = 1) when granting access and a BT output isolation
> + * (0x6A[15] = 1) when releasing it.
> + */
> + rtw_write8_set(rtwdev, 0x6b, on ? BIT(6) : BIT(7));
By comment above, I guess you can give proper names for 0x6b and bit 6 and 7.
> +
> + rtw8723x_efuse_grant(rtwdev, on);
> +}
> +
[...]
> +static u8 rtw8723b_default_ofdm_index(struct rtw_dev *rtwdev)
> +{
> + u8 i;
> + u32 val32;
> + u32 swing;
Reverse x'mas tree order. (Please apply to whole patchset)
> +
> + swing = rtw_read32_mask(rtwdev, REG_OFDM_0_XA_TX_IQ_IMBALANCE, 0xffc00000);
> +
> + for (i = 0; i < RTW_OFDM_SWING_TABLE_SIZE; i++) {
> + val32 = rtw8723b_ofdm_swing_table[i];
> +
> + if (val32 >= 0x100000)
> + val32 >>= 22;
I think shift 22 bits because of 0xffc00000.
Add a name for 0xffc00000 and use __ffs() to get the shift.
> +
> + if (val32 == swing)
> + break;
> + }
> +
> + if (i >= RTW_OFDM_SWING_TABLE_SIZE)
> + i = 30;
A comment for 30.
/* 30, +0dB */
> +
> + return i;
> +}
> +
> +static u8 rtw8723b_default_cck_index(struct rtw_dev *rtwdev)
> +{
> + u8 i;
> + u8 swing;
> +
> + swing = rtw_read8(rtwdev, rtw8723b_cck_pwr_regs[0]);
> +
> + for (i = 0; i < RTW_CCK_SWING_TABLE_SIZE; i++) {
> + if (rtw8723b_cck_swing_table_ch1_ch13[i][0] == swing)
> + break;
> + }
> +
> + if (i >= RTW_CCK_SWING_TABLE_SIZE)
> + i = 20;
A comment for 20.
> +
> + return i;
> +}
> +
> +static void rtw8723b_pwrtrack_init(struct rtw_dev *rtwdev)
> +{
> + struct rtw_dm_info *dm_info = &rtwdev->dm_info;
> + u8 path;
> +
> + dm_info->default_ofdm_index = rtw8723b_default_ofdm_index(rtwdev);
> + dm_info->default_cck_index = rtw8723b_default_cck_index(rtwdev);
> +
> + /* Clear the OFDM remnant per path: tracking keeps one per path. */
> + for (path = RF_PATH_A; path < rtwdev->hal.rf_path_num; path++) {
> + ewma_thermal_init(&dm_info->avg_thermal[path]);
> + dm_info->delta_power_index[path] = 0;
> + dm_info->txagc_remnant_ofdm[path] = 0;
> + }
> + dm_info->pwr_trk_triggered = false;
> + dm_info->pwr_trk_init_trigger = true;
> + dm_info->thermal_meter_k = rtwdev->efuse.thermal_meter_k;
> + dm_info->txagc_remnant_cck = 0;
> +}
> +
> +static bool rtw8723b_sdio_needs_rx_path_fix(struct rtw_dev *rtwdev)
What does it mean?
In many places using this function are not RX path.
> +{
> + return rtw_hci_type(rtwdev) == RTW_HCI_TYPE_SDIO;
> +}
> +
[...]
> +static void rtw8723b_phy_bb_config(struct rtw_dev *rtwdev)
> +{
> + u8 xtal_cap;
> +
> + /* Enable BB and RF */
> + rtw_write16_set(rtwdev, REG_SYS_FUNC_EN,
> + BIT_FEN_EN_25_1 | BIT_FEN_BB_GLB_RST | BIT_FEN_BB_RSTB);
> +
> + if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_USB)
> + rtw_write32(rtwdev, REG_BB_SEL_BTG, 0x0);
> + else
> + rtw_write32(rtwdev, REG_BB_SEL_BTG, 0x280);
> +
> + /* Full write: preserving spuriously set bits can wedge the RF bus. */
> + rtw_write8(rtwdev, REG_RF_CTRL,
> + BIT_RF_EN | BIT_RF_RSTB | BIT_RF_SDM_RSTB);
> + usleep_range(1000, 1100);
just fsleep() ?
> + rtw_write_rf(rtwdev, RF_PATH_A, RF_WLINT, RFREG_MASK, 0x0780);
> + rtw_write8(rtwdev, REG_SYS_FUNC_EN,
> + BIT_FEN_PPLL | BIT_FEN_PCIEA | BIT_FEN_DIO_PCIE |
> + BIT_FEN_BB_GLB_RST | BIT_FEN_BB_RSTB);
> + rtw_write8(rtwdev, REG_AFE_CTRL1 + 1, 0x80);
> +
> + xtal_cap = rtwdev->efuse.crystal_cap & 0x3f;
> + rtw_write32_mask(rtwdev, REG_AFE_CTRL3, BIT_MASK_XTAL,
> + xtal_cap | (xtal_cap << 6));
> +}
> +
[...]
> +
> +static void rtw8723b_phy_rf6052_config(struct rtw_dev *rtwdev)
> +{
> + struct rtw_hal *hal = &rtwdev->hal;
> + u32 intf_s, intf_oe, hssi_2;
> + u32 val32, mask;
> + u8 path;
> +
> + for (path = RF_PATH_A; path < hal->rf_path_num; path++) {
[...]
> + }
> +
> + /* 3 Configuration of Tx Power Tracking */
This comment looks weird.
> +}
> +
[...]
> +
> +static void rtw8723b_init_network_type(struct rtw_dev *rtwdev)
> +{
> + u32 val32;
> +
> + val32 = rtw_read32(rtwdev, REG_CR);
> + val32 = (val32 & ~MASK_NETTYPE) | _NETTYPE(NT_LINK_AP);
> + rtw_write32(rtwdev, REG_CR, val32);
This is what I point above. Please reconsider this.
> +}
> +
> +static void rtw8723b_init_wmac_setting(struct rtw_dev *rtwdev)
> +{
> + /* Override the default rcr filter for 8723B */
> + rtwdev->hal.rcr = WLAN_RCR_CFG;
Why? The default value doesn't work to RTL8723B?
rtwdev->hal.rcr = BIT_APP_FCS | BIT_APP_MIC | BIT_APP_ICV |
BIT_PKTCTL_DLEN | BIT_HTC_LOC_CTRL | BIT_APP_PHYSTS |
BIT_AB | BIT_AM | BIT_APM;
> + rtw_write32(rtwdev, REG_RCR, rtwdev->hal.rcr);
> +
> + rtw_write32(rtwdev, REG_MAR, 0xffffffff);
> + rtw_write32(rtwdev, REG_MAR + 4, 0xffffffff);
> +
> + rtw_write16(rtwdev, REG_RXFLTMAP2, WLAN_RX_FILTER2);
> + rtw_write16(rtwdev, REG_RXFLTMAP1, WLAN_RX_FILTER1);
> + rtw_write16(rtwdev, REG_RXFLTMAP0, WLAN_RX_FILTER0);
> +}
> +
[...]
> +
> +static void rtw8723b_init_antenna_selection(struct rtw_dev *rtwdev)
> +{
> + /* BIT(7) lets the 8051 control antenna selection, BIT(1) is LED2_CM. */
Just define names for these bits?
> + rtw_write8(rtwdev, REG_LEDCFG2, BIT(7) | BIT(1));
> +}
> +
[...]
> +static void rtw8723b_phy_set_param(struct rtw_dev *rtwdev)
> +{
> + const struct rtw_chip_info *chip = rtwdev->chip;
> + u32 val32;
> +
> + rtw8723b_post_enable_flow(rtwdev);
> +
> + rtw_load_table(rtwdev, chip->mac_tbl);
> + rtw8723b_phy_bb_config(rtwdev);
> + rtw8723b_phy_load_bb_tables(rtwdev);
> + rtw8723b_phy_rf_config(rtwdev);
> +
> + /* enable CCK and OFDM block */
> + rtw_write32_set(rtwdev, REG_FPGA0_RFMOD, BIT_CCKEN | BIT_OFDMEN);
> +
> + rtw8723b_init_tx_buffer_boundary(rtwdev);
> + rtw8723b_init_page_boundary(rtwdev);
> + rtw8723b_init_transfer_page_size(rtwdev);
> + rtw8723b_init_driver_info_size(rtwdev);
> + rtw8723b_init_network_type(rtwdev);
> +
> + rtw8723b_init_wmac_setting(rtwdev);
> +
> + rtw8723b_init_adaptive_ctrl(rtwdev);
> + rtw8723b_init_edca(rtwdev);
> + rtw8723b_init_retry_function(rtwdev);
So RTL8723B is very different from existing chips?
[...]
> +static void rtw8723b_reassert_rx_path(struct rtw_dev *rtwdev)
> +{
> + u32 rf_wlint_before;
> + u32 rx_path_before;
> + u32 fpga0_before;
> + u8 sys_func_before;
> + u8 rf_ctrl_before;
Reverse X'mas tree
> +
> + if (!rtw8723b_sdio_needs_rx_path_fix(rtwdev))
> + return;
> +
> + sys_func_before = rtw_read8(rtwdev, REG_SYS_FUNC_EN);
> + rf_ctrl_before = rtw_read8(rtwdev, REG_RF_CTRL);
> + fpga0_before = rtw_read32(rtwdev, REG_FPGA0_RFMOD);
> + rx_path_before = rtw_read32(rtwdev, REG_BB_RX_PATH_11N);
> + rf_wlint_before = rtw_read_rf(rtwdev, RF_PATH_A, RF_WLINT, RFREG_MASK);
> +
> + if ((sys_func_before & WLAN_SYS_FUNC_BB_ENABLE) !=
> + WLAN_SYS_FUNC_BB_ENABLE) {
> + rtw_write8_set(rtwdev, REG_SYS_FUNC_EN,
> + WLAN_SYS_FUNC_BB_ENABLE);
> + }
No need brace for single line branch. (apply this to whole patches)
[...]
> +const struct rtw_chip_info rtw8723b_hw_spec = {
Please take rtw8822c_hw_spec as template to align the style including
blank lines and order.
> + .ops = &rtw8723b_ops,
> + .id = RTW_CHIP_TYPE_8723B,
> + .fw_name = "rtw88/rtw8723b_fw.bin",
> + .wlan_cpu = RTW_WCPU_8051,
> + .tx_pkt_desc_sz = 40,
> + .tx_buf_desc_sz = 16,
> + .rx_pkt_desc_sz = 24,
> + .rx_buf_desc_sz = 8,
> + .phy_efuse_size = 512,
> + .log_efuse_size = 512,
> + .ptct_efuse_size = 15,
> +
> + .txff_size = 32768,
> + .rxff_size = 16384,
> + .rsvd_drv_pg_num = 8,
> +
> + .txgi_factor = 1,
> + .is_pwr_by_rate_dec = true,
> + .rx_ldpc = false,
> + .tx_stbc = false,
> +
> + .max_power_index = 0x3f,
> +
> + .csi_buf_pg_num = 0,
> + .band = RTW_BAND_2G,
> + .page_size = TX_PAGE_SIZE,
> +
> + .dig_min = 0x20,
> + .usb_tx_agg_desc_num = 1,
> +
> + /*
> + * The firmware reports id 0xfd instead of C2H_HW_FEATURE_REPORT, so
> + * the hardware feature report is not supported on this chip.
> + */
> + .hw_feature_report = false,
> +
> + .c2h_ra_report_size = 4, /* rtw88/rtw8723b_fw.bin v41 emits the
> + * legacy 8051 4-byte rate report
> + * (rate_sgi, mac_id, byte2, status).
> + * Setting this to 7, like the upstream
> + * default, caused every C2H_RA_REPORT
> + * to be dropped with
> + * "short ra report c2h length 4
> + * expected 7" on every connect attempt
> + * so the firmware-driven rate adaptation
> + * feedback path
> + * never updated si->ra_report. The
> + * legacy 8051 8723b/8703b/8723d firmware
> + * uses the same 4-byte format as the
> + * older 8821a/8812a chips. byte4..bw fall
> + * back to the per-station defaults in
> + * rtw_fw_ra_report_iter(), which matches
> + * what those chips already do safely.
> + */
I don't know if these comment is actually useful for people?
> + /* See commit c7706b1173c7 ("wifi: rtw88: Enable data rate fallback for
> + * older chips").
> + */
Why do you need this? Just by 'git blame' ?
> + .old_datarate_fb_limit = true,
> +
> + .path_div_supported = false,
> + .ht_supported = true,
> + .vht_supported = false,
> + .lps_deep_mode_supported = 0,
> +
> + .sys_func_en = 0xfd,
> + .pwr_on_seq = card_enable_flow_8723b,
> + .pwr_off_seq = card_disable_flow_8723b,
> + .page_table = page_table_8723b,
> +
> + .rqpn_table = rqpn_table_8723b,
> + /* same shared table as the sibling rtw8703b and rtw8723d */
> + .prioq_addrs = &rtw8723x_common.prioq_addrs,
> +
> + /* used only in pci.c, not needed for SDIO devices */
> + .intf_table = NULL,
> +
> + .dig = rtw8723x_common.dig,
> + .dig_cck = rtw8723x_common.dig_cck,
> +
> + .rf_sipi_addr = {0x840, 0x844},
> + .rf_sipi_read_addr = rtw8723x_common.rf_sipi_addr,
> +
> + .fix_rf_phy_num = 2,
> +
> + /* This chip has no LTE coex registers. */
> + .ltecoex_addr = NULL,
> +
> + .mac_tbl = &rtw8723b_mac_tbl,
> + .agc_tbl = &rtw8723b_agc_tbl,
> + .bb_tbl = &rtw8723b_bb_tbl,
> + .rf_tbl = {&rtw8723b_rf_a_tbl},
> +
> + .rfe_defs = rtw8723b_rfe_defs,
> + .rfe_defs_size = ARRAY_SIZE(rtw8723b_rfe_defs),
> + .iqk_threshold = 8,
> + .ampdu_density = IEEE80211_HT_MPDU_DENSITY_16,
> + .max_scan_ie_len = IEEE80211_MAX_DATA_LEN,
> +
> + .coex_para_ver = 20180201, /* glcoex_ver_date_8723b_1ant */
> + .bt_desired_ver = 0x6d,
> + .scbd_support = false,
> + .new_scbd10_def = true,
> + .ble_hid_profile_support = false,
> + .wl_mimo_ps_support = false,
> + .pstdma_type = COEX_PSTDMA_FORCE_LPSOFF,
> + .bt_rssi_type = COEX_BTRSSI_RATIO,
> + .ant_isolation = 15,
> + .rssi_tolerance = 2,
> + .wl_rssi_step = wl_rssi_step_8723b,
> + .bt_rssi_step = bt_rssi_step_8723b,
> + .table_sant_num = ARRAY_SIZE(table_sant_8723b),
> + .table_sant = table_sant_8723b,
> + .table_nsant_num = ARRAY_SIZE(table_nsant_8723b),
> + .table_nsant = table_nsant_8723b,
> + .tdma_sant_num = ARRAY_SIZE(tdma_sant_8723b),
> + .tdma_sant = tdma_sant_8723b,
> + .tdma_nsant_num = ARRAY_SIZE(tdma_nsant_8723b),
> + .tdma_nsant = tdma_nsant_8723b,
> + .wl_rf_para_num = ARRAY_SIZE(rf_para_tx_8723b),
> + .wl_rf_para_tx = rf_para_tx_8723b,
> + .wl_rf_para_rx = rf_para_rx_8723b,
> + .bt_afh_span_bw20 = 0x20,
> + .bt_afh_span_bw40 = 0x30,
> + .afh_5g_num = ARRAY_SIZE(afh_5g_8723b),
> + .afh_5g = afh_5g_8723b,
> + /* BTG_SEL is driven by the cardemu_to_act power sequence instead. */
> + .btg_reg = NULL,
> +
> + .coex_info_hw_regs_num = 0,
> + .coex_info_hw_regs = NULL,
> +};
> +EXPORT_SYMBOL(rtw8723b_hw_spec);
> +
> +MODULE_FIRMWARE("rtw88/rtw8723b_fw.bin");
> +
> +MODULE_AUTHOR("Luka Gejak <luka.gejak@linux.dev>");
> +MODULE_AUTHOR("Michael Straube <straube.linux@gmail.com>");
> +MODULE_DESCRIPTION("Realtek 802.11n wireless 8723b driver");
> +MODULE_LICENSE("Dual BSD/GPL");
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723b.h
> b/drivers/net/wireless/realtek/rtw88/rtw8723b.h
> new file mode 100644
> index 000000000000..2fe00e709620
> --- /dev/null
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8723b.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
> +/* Copyright(c) 2018-2019 Realtek Corporation
Please let copyright consistent.
> + */
> +
> +#ifndef __RTW8723B_H__
> +#define __RTW8723B_H__
> +
> +#include "rtw8723x.h"
> +
> +extern const struct rtw_chip_info rtw8723b_hw_spec;
> +
> +#endif
> --
> 2.55.0
next prev parent reply other threads:[~2026-09-23 8:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 15:43 [PATCH v3 0/6] wifi: rtw88: add RTL8723B/RTL8723BS support Luka Gejak
2026-09-21 15:43 ` [PATCH v3 1/6] wifi: rtw88: 8723b: add the RTL8723B register definitions Luka Gejak
2026-09-23 7:44 ` Ping-Ke Shih
2026-09-21 15:43 ` [PATCH v3 2/6] wifi: rtw88: 8723b: add the RTL8723B BB, RF and AGC tables Luka Gejak
2026-09-23 7:50 ` Ping-Ke Shih
2026-09-23 8:27 ` Luka Gejak
2026-09-23 8:34 ` Ping-Ke Shih
2026-09-23 8:44 ` Luka Gejak
2026-09-23 8:59 ` Ping-Ke Shih
2026-09-23 9:09 ` Luka Gejak
2026-09-21 15:43 ` [PATCH v3 3/6] wifi: rtw88: 8723b: add the RTL8723B chip driver Luka Gejak
2026-09-23 8:30 ` Ping-Ke Shih [this message]
2026-09-23 21:50 ` Luka Gejak
2026-09-24 3:11 ` Ping-Ke Shih
2026-09-24 8:30 ` Luka Gejak
2026-09-29 2:04 ` Ping-Ke Shih
2026-09-29 6:26 ` Luka Gejak
2026-09-28 6:25 ` Johannes Berg
2026-09-28 6:57 ` Luka Gejak
2026-09-27 17:37 ` Bitterblue Smith
2026-09-21 15:43 ` [PATCH v3 4/6] wifi: rtw88: 8723bs: add the RTL8723BS SDIO bind Luka Gejak
2026-09-23 9:04 ` Ping-Ke Shih
2026-09-21 15:43 ` [PATCH v3 5/6] wifi: rtw88: 8723bs: enable building the RTL8723BS driver Luka Gejak
2026-09-21 15:43 ` [PATCH v3 6/6] MAINTAINERS: add entry for the RTL8723B rtw88 driver Luka Gejak
2026-09-21 16:25 ` Johannes Berg
2026-09-21 16:49 ` Luka Gejak
2026-09-21 18:14 ` Johannes Berg
2026-09-21 22:35 ` Jeff Johnson
2026-09-21 23:53 ` Luka Gejak
2026-09-22 0:28 ` Ping-Ke Shih
2026-09-22 0:43 ` Luka Gejak
2026-09-22 0:50 ` Ping-Ke Shih
2026-09-22 1:07 ` Luka Gejak
2026-09-24 1:42 ` Ping-Ke Shih
2026-09-24 17:43 ` Jeff Johnson
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=39da13e5cdd840f5a5ab86ded478d07c@realtek.com \
--to=pkshih@realtek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luka.gejak@linux.dev \
--cc=pbrobinson@gmail.com \
--cc=rtl8821cerfe2@gmail.com \
--cc=straube.linux@gmail.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 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.