Commit 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API
misuse") moved the wiphy_apply_custom_regulatory() call to earlier in the
driver's init-sequence, so that it gets called before wiphy_register().
But at this point in time the eFuses which code the regulatory-settings
for the chip have not been read by the driver yet, causing
_rtw_reg_apply_flags() to set the IEEE80211_CHAN_DISABLED flag on *all*
channels.
On the device where I initially tested the fix, a Jumper EZpad 7 tablet,
this does not cause any problems because shortly after init the
rtw_reg_notifier() gets called fixing things up. I guess this happens
into response to receiving a (broadcast) packet with regulatory info
from the access-point ?
But on another device with a RTL8723BS wifi chip, an Acer Switch 10E
(SW3-016), the rtw_reg_notifier() never gets called. I assume that some
fuse has been set on this device to ignore regulatory info received from
access-points.
This means that on the Acer the driver is stuck in a state with all
channels disabled, leading to non working Wifi.
We cannot move the wiphy_apply_custom_regulatory() call back, because
that call must be made before the wiphy_register() call.
Instead move the entire rtw_wdev_alloc() call to after the Efuses have
been read, fixing all channels being disabled in the initial channel-map.
Fixes: 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API misuse")
Cc: Johannes Berg <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index b2208e5f190a..301ffff12e82 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -339,8 +339,6 @@ static struct adapter *rtw_sdio_if1_init(struct dvobj_priv *dvobj, const struct
padapter = rtw_netdev_priv(pnetdev);
- rtw_wdev_alloc(padapter, dvobj_to_dev(dvobj));
-
/* 3 3. init driver special setting, interface, OS and hardware relative */
/* 4 3.1 set hardware operation functions */
@@ -378,6 +376,8 @@ static struct adapter *rtw_sdio_if1_init(struct dvobj_priv *dvobj, const struct
goto free_hal_data;
}
+ rtw_wdev_alloc(padapter, dvobj_to_dev(dvobj));
+
/* 3 8. get WLan MAC address */
/* set mac addr */
rtw_macaddr_cfg(&psdio->func->dev, padapter->eeprompriv.mac_addr);
--
2.29.2
On Mon, Feb 01, 2021 at 04:29:56PM +0100, Hans de Goede wrote:
> Commit 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API
> misuse") moved the wiphy_apply_custom_regulatory() call to earlier in the
> driver's init-sequence, so that it gets called before wiphy_register().
>
> But at this point in time the eFuses which code the regulatory-settings
> for the chip have not been read by the driver yet, causing
> _rtw_reg_apply_flags() to set the IEEE80211_CHAN_DISABLED flag on *all*
> channels.
>
> On the device where I initially tested the fix, a Jumper EZpad 7 tablet,
> this does not cause any problems because shortly after init the
> rtw_reg_notifier() gets called fixing things up. I guess this happens
> into response to receiving a (broadcast) packet with regulatory info
> from the access-point ?
>
> But on another device with a RTL8723BS wifi chip, an Acer Switch 10E
> (SW3-016), the rtw_reg_notifier() never gets called. I assume that some
> fuse has been set on this device to ignore regulatory info received from
> access-points.
>
> This means that on the Acer the driver is stuck in a state with all
> channels disabled, leading to non working Wifi.
>
> We cannot move the wiphy_apply_custom_regulatory() call back, because
> that call must be made before the wiphy_register() call.
>
> Instead move the entire rtw_wdev_alloc() call to after the Efuses have
> been read, fixing all channels being disabled in the initial channel-map.
>
> Fixes: 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API misuse")
> Cc: Johannes Berg <[email protected]>
> Signed-off-by: Hans de Goede <[email protected]>
> ---
> drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
As the problem-fix came from Johannes's tree, I have no problem with
this fix going in through that as well:
Acked-by: Greg Kroah-Hartman <[email protected]>
On Mon, 2021-02-01 at 16:37 +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 01, 2021 at 04:29:56PM +0100, Hans de Goede wrote:
> > Commit 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API
> > misuse") moved the wiphy_apply_custom_regulatory() call to earlier in the
> > driver's init-sequence, so that it gets called before wiphy_register().
> >
> > But at this point in time the eFuses which code the regulatory-settings
> > for the chip have not been read by the driver yet, causing
> > _rtw_reg_apply_flags() to set the IEEE80211_CHAN_DISABLED flag on *all*
> > channels.
> >
> > On the device where I initially tested the fix, a Jumper EZpad 7 tablet,
> > this does not cause any problems because shortly after init the
> > rtw_reg_notifier() gets called fixing things up. I guess this happens
> > into response to receiving a (broadcast) packet with regulatory info
> > from the access-point ?
> >
> > But on another device with a RTL8723BS wifi chip, an Acer Switch 10E
> > (SW3-016), the rtw_reg_notifier() never gets called. I assume that some
> > fuse has been set on this device to ignore regulatory info received from
> > access-points.
> >
> > This means that on the Acer the driver is stuck in a state with all
> > channels disabled, leading to non working Wifi.
> >
> > We cannot move the wiphy_apply_custom_regulatory() call back, because
> > that call must be made before the wiphy_register() call.
> >
> > Instead move the entire rtw_wdev_alloc() call to after the Efuses have
> > been read, fixing all channels being disabled in the initial channel-map.
> >
> > Fixes: 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API misuse")
> > Cc: Johannes Berg <[email protected]>
> > Signed-off-by: Hans de Goede <[email protected]>
> > ---
> > drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> As the problem-fix came from Johannes's tree, I have no problem with
> this fix going in through that as well:
>
> Acked-by: Greg Kroah-Hartman <[email protected]>
So we'll have problem-fix-fix ;-)
Sounds good to me, I'll pick it up.
Thanks!
johannes
Hello, "cfg80211: Save the regulatory domain when setting custom
regulatory" "cfg80211: Save the regulatory domain with a lock" cause
rtl8723bs not work problem.
I see upstream rtl8723bs driver "staging: rtl8723bs: Move wiphy setup
to after reading the regulatory" "staging: rtl8723bs: fix wireless
regulatory API misuse" fix problem.
I use rtl8723bs v5.2.17.1_26955.20180307_COEX20180201-6f52 driver, no
the "rtw_wdev_alloc(padapter, dvobj_to_dev(dvobj));"
https://github.com/youling257/rockchip_wlan/blob/v5.2.17.1/rtl8723bs/os_dep/linux/ioctl_cfg80211.h#L234
int rtw_wdev_alloc(_adapter *padapter, struct wiphy *wiphy);
https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8723bs/include/ioctl_cfg80211.h#L91
int rtw_wdev_alloc(struct adapter *padapter, struct device *dev);
https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8723bs/os_dep/sdio_intf.c#L333
https://github.com/youling257/rockchip_wlan/blob/v5.2.17.1/rtl8723bs/os_dep/linux/sdio_intf.c#L645
I want to fix rtl8723bs v5.2.17 not work problem, can you help me?
Hi Youling,
On 4/26/21 8:34 PM, youling257 wrote:
> Hello, "cfg80211: Save the regulatory domain when setting custom
> regulatory" "cfg80211: Save the regulatory domain with a lock" cause
> rtl8723bs not work problem.
> I see upstream rtl8723bs driver "staging: rtl8723bs: Move wiphy setup
> to after reading the regulatory" "staging: rtl8723bs: fix wireless
> regulatory API misuse" fix problem.
>
> I use rtl8723bs v5.2.17.1_26955.20180307_COEX20180201-6f52 driver, no
> the "rtw_wdev_alloc(padapter, dvobj_to_dev(dvobj));"
>
> https://github.com/youling257/rockchip_wlan/blob/v5.2.17.1/rtl8723bs/os_dep/linux/ioctl_cfg80211.h#L234
> int rtw_wdev_alloc(_adapter *padapter, struct wiphy *wiphy);
>
> https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8723bs/include/ioctl_cfg80211.h#L91
> int rtw_wdev_alloc(struct adapter *padapter, struct device *dev);
>
> https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8723bs/os_dep/sdio_intf.c#L333
> https://github.com/youling257/rockchip_wlan/blob/v5.2.17.1/rtl8723bs/os_dep/linux/sdio_intf.c#L645
>
> I want to fix rtl8723bs v5.2.17 not work problem, can you help me?
I'm not sure what your problem exactly is. If your kernel contains the
51d62f2f2c50 ("cfg80211: Save the regulatory domain with a lock")
Commit then you also need to backport (in the listed order):
81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API misuse")
50af06d43eab ("taging: rtl8723bs: Move wiphy setup to after reading the regulatory settings from the chip")
Which you seem to have already figured out ?
To keep the rtk8723bs driver working your kernel should either contain all 3 mentioned commits,
or it should contain none of them.
Regards,
Hans
rtl8723bs v5.2.17 is a external module, i not use staging/rtl8723bs
driver, rtl8723bs v5.2.17 support build with linux kernel 5.12.
How to porting "staging: rtl8723bs: Move wiphy setup to after reading
the regulatory …" to my rtl8723bs v5.2.17 ?
my rtl8723bs v5.2.17, there are no such codes.
/* 3 1. init network device data */
pnetdev = rtw_init_netdev(padapter);
if (!pnetdev)
goto free_adapter;
SET_NETDEV_DEV(pnetdev, dvobj_to_dev(dvobj));
padapter = rtw_netdev_priv(pnetdev);
rtw_wdev_alloc(padapter, dvobj_to_dev(dvobj));
2021-04-27 2:43 GMT+08:00, Hans de Goede <[email protected]>:
> Hi Youling,
>
> On 4/26/21 8:34 PM, youling257 wrote:
>> Hello, "cfg80211: Save the regulatory domain when setting custom
>> regulatory" "cfg80211: Save the regulatory domain with a lock" cause
>> rtl8723bs not work problem.
>> I see upstream rtl8723bs driver "staging: rtl8723bs: Move wiphy setup
>> to after reading the regulatory" "staging: rtl8723bs: fix wireless
>> regulatory API misuse" fix problem.
>>
>> I use rtl8723bs v5.2.17.1_26955.20180307_COEX20180201-6f52 driver, no
>> the "rtw_wdev_alloc(padapter, dvobj_to_dev(dvobj));"
>>
>> https://github.com/youling257/rockchip_wlan/blob/v5.2.17.1/rtl8723bs/os_dep/linux/ioctl_cfg80211.h#L234
>> int rtw_wdev_alloc(_adapter *padapter, struct wiphy *wiphy);
>>
>> https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8723bs/include/ioctl_cfg80211.h#L91
>> int rtw_wdev_alloc(struct adapter *padapter, struct device *dev);
>>
>> https://github.com/torvalds/linux/blob/master/drivers/staging/rtl8723bs/os_dep/sdio_intf.c#L333
>> https://github.com/youling257/rockchip_wlan/blob/v5.2.17.1/rtl8723bs/os_dep/linux/sdio_intf.c#L645
>>
>> I want to fix rtl8723bs v5.2.17 not work problem, can you help me?
>
> I'm not sure what your problem exactly is. If your kernel contains the
>
> 51d62f2f2c50 ("cfg80211: Save the regulatory domain with a lock")
>
> Commit then you also need to backport (in the listed order):
>
> 81f153faacd0 ("staging: rtl8723bs: fix wireless regulatory API misuse")
> 50af06d43eab ("taging: rtl8723bs: Move wiphy setup to after reading the
> regulatory settings from the chip")
>
> Which you seem to have already figured out ?
>
> To keep the rtk8723bs driver working your kernel should either contain all 3
> mentioned commits,
> or it should contain none of them.
>
> Regards,
>
> Hans
>
>
>
On Tue, Apr 27, 2021 at 09:34:36AM +0800, youling 257 wrote:
> rtl8723bs v5.2.17 is a external module, i not use staging/rtl8723bs
> driver, rtl8723bs v5.2.17 support build with linux kernel 5.12.
There is not much we can do about external driver code, please work to
fix up the in-kernel driver if there are any gaps in functionality in it
that is preventing you from using it.
thanks,
greg k-h