I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false
After pointing this out, Larry Finger informed what would be the correct one.
'(X & 0x3) == 0x3'
Signed-off-by: Rickard Strandqvist <[email protected]>
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
index 1b8583b..52322e3 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
@@ -1623,7 +1623,7 @@ static int _rtl8821ae_set_media_status(struct ieee80211_hw *hw,
rtl_write_byte(rtlpriv, (MSR), bt_msr);
rtlpriv->cfg->ops->led_control(hw, ledaction);
- if ((bt_msr & ~0xfc) == MSR_AP)
+ if ((bt_msr & MSR_AP) == MSR_AP)
rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
else
rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
--
1.7.10.4
On Sun, 8 Jun 2014, Rickard Strandqvist wrote:
> I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false
>
The test you're changing is '(X & ~0xfc) == 0x3' which is not always
false, so is (bt_msr & MSR_AP) == MSR_AP or (bt_msr & ~MSR_AP) == MSR_AP
correct? Either way, your changelog makes no sense in combination with
your patch.
> After pointing this out, Larry Finger informed what would be the correct one.
> '(X & 0x3) == 0x3'
>
> Signed-off-by: Rickard Strandqvist <[email protected]>
> ---
> drivers/staging/rtl8821ae/rtl8821ae/hw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> index 1b8583b..52322e3 100644
> --- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> +++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> @@ -1623,7 +1623,7 @@ static int _rtl8821ae_set_media_status(struct ieee80211_hw *hw,
>
> rtl_write_byte(rtlpriv, (MSR), bt_msr);
> rtlpriv->cfg->ops->led_control(hw, ledaction);
> - if ((bt_msr & ~0xfc) == MSR_AP)
> + if ((bt_msr & MSR_AP) == MSR_AP)
> rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00);
> else
> rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66);
On Sun, Jun 08, 2014 at 01:37:43PM -0700, David Rientjes wrote:
> > drivers/staging/rtl8821ae/rtl8821ae/hw.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> > index 1b8583b..52322e3 100644
> > --- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> > +++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
> > @@ -1623,7 +1623,7 @@ static int _rtl8821ae_set_media_status(struct ieee80211_hw *hw,
> >
> > rtl_write_byte(rtlpriv, (MSR), bt_msr);
> > rtlpriv->cfg->ops->led_control(hw, ledaction);
> > - if ((bt_msr & ~0xfc) == MSR_AP)
> > + if ((bt_msr & MSR_AP) == MSR_AP)
I changed this line from '0xfc' to '~0xfc', and looking at the defines
it must have been the way your patch does, so:
Acked-by: Levente Kurusa <[email protected]>
if it wasn't applied yet, and you fix the problems David pointed out
with the commit message.
Thanks,
Levente Kurusa