| Message ID | 20210201152956.370186-2-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | staging: rtl8723bs: Move wiphy setup to after reading the regulatory settings from the chip | expand |
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 <johannes.berg@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > 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 <gregkh@linuxfoundation.org>
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 <johannes.berg@intel.com> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > --- > > 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 <gregkh@linuxfoundation.org> 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 <hdegoede@redhat.com>: > 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
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);
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 <johannes.berg@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)