mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  reply	other threads:[~2026-09-23  8:31 UTC|newest]

Thread overview: 26+ 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-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

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 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®