Re: [PATCH 1/1] staging: rtl8723bs: Move wiphy setup to after reading the regulatory settings from the chip

[Johannes Berg <johannes@sipsolutions.net>]

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