staging: rtl8723bs: possible dead code in GetDeltaSwingTable_8723B (5GHz fallback path)

staging: rtl8723bs: possible dead code in GetDeltaSwingTable_8723B (5GHz fallback path)

[Hank Yang]

Hi Greg and staging maintainers,

I believe I've found dead code in
drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c — a fallback branch
in GetDeltaSwingTable_8723B() that can never execute, since it uses
calibration tables from a different chip (8188E). If my reasoning
below holds, I'd like to remove this else branch, but I wanted to
check with you first before sending a patch. Details below:

    if (channel >= 1 && channel <= 14) {
            // ... uses genuine 8723B calibration tables from pRFCalibrateInfo
    } else {
            *TemperatureUP_A   = (u8 *)DeltaSwingTableIdx_2GA_P_8188E;
            *TemperatureDOWN_A = (u8 *)DeltaSwingTableIdx_2GA_N_8188E;
            *TemperatureUP_B   = (u8 *)DeltaSwingTableIdx_2GA_P_8188E;
            *TemperatureDOWN_B = (u8 *)DeltaSwingTableIdx_2GA_N_8188E;
    }

The else branch only executes when `channel` is outside the range of
1 to 14. This `channel` value comes from `CurrentChannel`, which is
only updated in rtl8723b_phycfg.c after passing a legality check
(the parameter is named `ChannelNum` there, and `Channel` in
HAL_IsLegalChannel() — same value, different local names):

    if (HAL_IsLegalChannel(Adapter, ChannelNum))
            pHalData->bSwChnl = true;
    ...
    if (pHalData->bSwChnl) {
            pHalData->CurrentChannel = ChannelNum;
    }

HAL_IsLegalChannel() returns a boolean (`bLegalChannel`) indicating
whether the channel is valid, and enforces a range of 1 to 14:

    bool HAL_IsLegalChannel(struct adapter *adapter, u32 Channel)
    {
            bool bLegalChannel = true;

            if ((Channel <= 14) && (Channel >= 1)) {
                    if (!is_supported_24g(adapter->registrypriv.wireless_mode))
                            bLegalChannel = false;
            } else {
                    bLegalChannel = false;
            }

            return bLegalChannel;
    }

Any channel value outside 1-14 is rejected here and never written to
`CurrentChannel`. As a result, `CurrentChannel` can never exceed the
range of 1 to 14, which means the else branch in
`GetDeltaSwingTable_8723B()` can never be executed.

Since GetDeltaSwingTable_8723B() is specific to the RTL8723BS chip,
I looked into whether this chip supports any frequency band outside
1-14 (i.e. 5GHz). According to Realtek's official product page [1]:

    "The Realtek RTL8723BS-VQ0-CG is an 802.11bgn 2.4G single-chip
    that integrates Wireless LAN (WLAN) and a network SDIO interface
    controller with integrated Bluetooth 2.1/3.0/4.0 controller."

I was unable to find the official datasheet for RTL8723BS itself
(only for the related RTL8723AS), so I also checked the FCC filing
for a device using this chip. The TX2-RTL8723BS user manual [2]
lists an operating frequency range of 2402-2480MHz, confirming this
is a 2.4GHz-only chip with no 5GHz capability.

[1] https://www.realtek.com/Product/Index?id=610&cate_id=194
[2] https://fccid.io/TX2-RTL8723BS/User-Manual/User-Manual-System-pdf-2365682

I've verified this logic by tracing through the code and cross-checking
against the public documentation above, using an LLM (Claude) to help
organize and validate each step of the reasoning. I don't have access
to RTL8723BS hardware, so I haven't been able to test this on real
silicon — this is purely a static code analysis.

Is this understanding correct, or is there a reason this fallback
exists that I'm missing (e.g. some legacy support I'm not aware of)?
If confirmed, I'd be happy to send a patch removing the dead branch.

Thanks,
Hank Yang

Re: staging: rtl8723bs: possible dead code in GetDeltaSwingTable_8723B (5GHz fallback path)

[Greg KH]

On Sat, Sep 05, 2026 at 09:22:41PM +0800, Hank Yang wrote:
> Hi Greg and staging maintainers,
> 
> I believe I've found dead code in
> drivers/staging/rtl8723bs/hal/HalPhyRf_8723B.c — a fallback branch
> in GetDeltaSwingTable_8723B() that can never execute, since it uses
> calibration tables from a different chip (8188E). If my reasoning
> below holds, I'd like to remove this else branch, but I wanted to
> check with you first before sending a patch. Details below:

There are loads of "dead code" in staging drivers, that's why they are
in staging :)

If you think it should be removed, then make a patch to remove it and
submit it and we will be glad to review it like any other submission.

thanks,

greg k-h