• Michal Kazior's avatar
    ath10k: fix spurious tx/rx during boot · 47b1848d
    Michal Kazior authored
    HW Rx filters and masks are not configured
    properly by firmware during boot sequences. The
    MAC_PCU_ADDR1 is set to 0s instead of 1s which
    allows the HW to ACK any frame that passes through
    MAC_PCU_RX_FILTER. The MAC_PCU_RX_FILTER itself
    is misconfigured on boot as well.
    
    The combination of these bugs ended up with the
    following manifestations:
     - "no channel configured; ignoring frame(s)!"
       warnings in the driver
     - spurious ACKs (transmission) on the air during
       firmware bootup sequences
    
    The former was a long standing and known bug
    originally though mostly harmless.
    
    However Marek recently discovered that this
    problem also involves ACKing *all* frames the HW
    receives (including beacons ;). Such frames
    are delivered to host and generate the former
    warning as well.
    
    This could be a problem with regulatory compliance
    in some rare cases (e.g. Taiwan which forbids
    transmissions on channel 36 which is the default
    bootup channel on 5Ghz band cards). The good news
    is that it'd require someone else to violate
    regulatory first to coerce our device to generate
    and transmit an ACK.
    
    The problem could be reproduced in a rather busy
    environment that has a lot of APs. The likelihood
    could be increased by injecting an msleep() of
    5000 or longer immediately after
    ath10k_htt_setup() in ath10k_core_start().
    
    The reason why the former warnings were only
    showing up seldom is because the device was either
    quickly reset again (i.e. during firmware probing)
    or wmi vdev was created (which fixes hw and fw
    states).
    
    It is technically possible for host driver to
    override adequate hw registers however this can't
    work reliably because the bug root cause lies in
    incorrect firmware state on boot (internal
    structure used to program MAC_PCU_ADDR1 is not
    properly initialized) and only vdev create/delete
    events can fix it. This is why the patch takes
    dummy vdev approach.
    
    This could be fixed in firmware as well but having
    this fixed in driver is more robust, most notably
    when thinking of users of older firmware such as
    999.999.0.636.
    Reported-by: default avatarMarek Puzyniak <marek.puzyniak@tieto.com>
    Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
    Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    47b1848d
core.c 59.6 KB