Colin King <colin.k...@canonical.com> writes: > From: Colin Ian King <colin.k...@canonical.com> > > BT_Active and BT_State are being masked with 0x00ffffff so it the subsequent > comparisons with 0xffffffff are therefore a buggy check. Instead, check them > against 0x00ffffff. > > Unfortunately I couldn't find a datasheet or hardware to see if 0xffffffff > is an expected invalid bit pattern that should be checked before BT_Active and > BT_State are masked with 0x00ffffff, so for now, this fix seems like the least > risky approach. > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> > --- > drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)
I don't really know about the BT parts here, since I never did anything with that part of the chip. Larry probably knows more. The only question is whether fixing this bug changes behavior that has unexpected side effects? Cheers, Jes > > diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c > b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c > index bfcbd7a..6989580 100644 > --- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c > +++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c > @@ -9824,7 +9824,7 @@ void BTDM_CheckBTIdleChange1Ant(struct rtw_adapter > *padapter) > BT_Polling = rtl8723au_read32(padapter, regBTPolling); > RTPRINT(FBT, BT_TRACE, ("[DM][BT], BT_Polling(0x%x) =%x\n", > regBTPolling, BT_Polling)); > > - if (BT_Active == 0xffffffff && BT_State == 0xffffffff && BT_Polling == > 0xffffffff) > + if (BT_Active == 0x00ffffff && BT_State == 0x00ffffff && BT_Polling == > 0xffffffff) > return; > if (BT_Polling == 0) > return; -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html