Re: [PATCH v4 3/6] wifi: rtw88: 8723b: add the RTL8723B chip driver

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 29/09/2026 13:13, Luka Gejak wrote:
> September 27, 2026 at 19:29, "Bitterblue Smith" <rtl8821cerfe2@gmail.com mailto:rtl8821cerfe2@gmail.com?to=%22Bitterblue%20Smith%22%20%3Crtl8821cerfe2%40gmail.com%3E > wrote:
> 
> 
>>
>> On 27/09/2026 18:21, Bitterblue Smith wrote:
>>
>>>
>>> On 24/09/2026 00:35, Luka Gejak wrote:
>>>
> 
>>>> +	if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_SDIO) {
>>>> +		rtw_write16_set(rtwdev, REG_PWR_DATA,
>>>> +				BIT_EEPRPAD_RFE_CTRL_EN);
>>>> +
>>>> +		/*
>>>> +		 * rtw_mac_power_on() sets PAD mux bits this chip must not have;
>>>> +		 * restore the SDIO PAD mux before RF and coex setup.
>>>> +		 */
> 
>> By the way, rtw_mac_power_on() doesn't touch REG_PAD_CTRL1
>> for this chip.
> 
> It does, through rtw_mac_pre_system_cfg(), which rtw_mac_power_on() calls
> at mac.c:382. At mac.c:111 that function reads REG_PAD_CTRL1, ORs in
> BIT_PAPE_WLBT_SEL and BIT_LNAON_WLBT_SEL and writes it back, for every
> HCI type including SDIO. So the bits are set during power on and the SDIO
> PAD mux has to have them cleared, which is what rtw8723b_sdio_restore_pad_ctrl()
> does. The comment in rtw8723b_post_enable_flow() names that function and the
> two bits now.

That code is not reachable with this chip.

> 
> Best regards,
> Luka Gejak