W dniu 17 lipca 2011 10:43 użytkownik Michael Büsch <m@xxxxxxx> napisał:
> On Sun, 17 Jul 2011 10:30:31 +0200
> Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
>
>> Old masks were causing ugly, delayed lock ups.
>>
>> Signed-off-by: Rafał Miłecki <zajec5@xxxxxxxxx>
>> ---
>> drivers/net/wireless/b43/phy_ht.c | 10 +++++-----
>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/b43/phy_ht.c b/drivers/net/wireless/b43/phy_ht.c
>> index 2982103..0cc293a 100644
>> --- a/drivers/net/wireless/b43/phy_ht.c
>> +++ b/drivers/net/wireless/b43/phy_ht.c
>> @@ -277,12 +277,12 @@ static void b43_phy_ht_op_software_rfkill(struct b43_wldev *dev,
>> b43err(dev->wl, "MAC not suspended\n");
>>
>> if (blocked) {
>> - b43_phy_mask(dev, B43_PHY_HT_RF_CTL1, ~0);
>> + b43_phy_mask(dev, B43_PHY_HT_RF_CTL1, 0);
>> } else {
>> - b43_phy_mask(dev, B43_PHY_HT_RF_CTL1, ~0);
>> - b43_phy_maskset(dev, B43_PHY_HT_RF_CTL1, ~0, 0x1);
>> - b43_phy_mask(dev, B43_PHY_HT_RF_CTL1, ~0);
>> - b43_phy_maskset(dev, B43_PHY_HT_RF_CTL1, ~0, 0x2);
>> + b43_phy_mask(dev, B43_PHY_HT_RF_CTL1, 0);
>> + b43_phy_maskset(dev, B43_PHY_HT_RF_CTL1, 0, 0x1);
>> + b43_phy_mask(dev, B43_PHY_HT_RF_CTL1, 0);
>> + b43_phy_maskset(dev, B43_PHY_HT_RF_CTL1, 0, 0x2);
>>
>> if (dev->phy.radio_ver == 0x2059)
>> b43_radio_2059_init(dev);
>
> Why are we using mask/maskset here at all, if the mask is zero?
> You could just use phy_write.
>
> (And mask() with ~0 should always ring a bell anyway, because it does
> nothing except for possible side effects of the register read/write).
Well, after re-thinking it, I've some doubts.
Thanks to using maskset we got read after every write. We have no idea
it this is needed or no. What we are really sure is that this part of
code is really sensitive. Writing 0x3 cause horrible lock ups, really
ugly to track.
Should we use read-after-write then? Or maybe just keep wl's dummy way
of operating on this register?
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
