23 Jun, 2011

12 commits

  • Consider the following situation:
    * a dump that would show 8 entries, four in the first
    round, and four in the second
    * between the first and second rounds, 6 entries are
    removed
    * now the second round will not show any entry, and
    even if there is a sequence/generation counter the
    application will not know

    To solve this problem, add a new flag NLM_F_DUMP_INTR
    to the netlink header that indicates the dump wasn't
    consistent, this flag can also be set on the MSG_DONE
    message that terminates the dump, and as such above
    situation can be detected.

    To achieve this, add a sequence counter to the netlink
    callback struct. Of course, netlink code still needs
    to use this new functionality. The correct way to do
    that is to always set cb->seq when a dumpit callback
    is invoked and call nl_dump_check_consistent() for
    each new message. The core code will also call this
    function for the final MSG_DONE message.

    To make it usable with generic netlink, a new function
    genlmsg_nlhdr() is needed to obtain the netlink header
    from the genetlink user header.

    Signed-off-by: Johannes Berg
    Acked-by: David S. Miller
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • After uploading radio values calibration goes in. In MMIO dump it is:
    radio_read(0x002b) -> 0x0008
    radio_write(0x002b) 0x0004
    radio_write(0x002e) 0x0000
    radio_write(0x002e) 0x0008
    radio_write(0x002b)
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • When module is reloaded, device may fail to work, with messages:

    [ 342.211926] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0059, type=2.
    [ 342.314254] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x004a, type=2.
    [ 342.416458] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 3183 max 2432.
    [ 342.518605] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00c9, type=2.
    [ 342.620836] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00ae, type=1.
    [ 342.723201] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
    [ 342.825399] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
    [ 342.927624] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
    [ 343.029804] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 2491 max 2432.
    [ 343.132008] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 2576 max 2432.
    [ 343.234326] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x004c, type=1.
    [ 343.438723] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00e6, type=1.

    Whereas replugging device make it functional. To solve that problem
    force reset device during probe.

    With patch messages are gone. Unfortunately device may sometimes
    still does not operate correctly after module reload (fail to receive
    data after associate), but such cases are rarer than without the patch.

    Signed-off-by: Stanislaw Gruszka
    Acked-by: Ivo van Doorn
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     
  • Sometimes rxdesc descriptor provided by hardware contains invalid
    (random) data. For example rxdesc.size can be bigger than actual
    size of the buffer. When this happen rt2x00crypto_rx_insert_iv()
    corrupt memory doing memmove outside of buffer boundaries.

    Signed-off-by: Stanislaw Gruszka
    Acked-by: Ivo van Doorn
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     
  • Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • Specs were recently updated.

    Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • Switching channel happens after specific SHM write to B43_SHM_SH_CHAN.
    This is the way we found it in BCM4331 MMIO dumps. By comparing with
    N-PHY code we noticed there is routing used for SYN and TX/RX.

    Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • The trick was to find 0x810 PHY reg ops close to analog enabling code.
    To find out proper masks and sets, MMIO hacks were used.

    Signed-off-by: Rafał Miłecki
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • Closed drivers kill radio right after reading radio version and MACCTL,
    so it was easy to find related PHY ops:
    phy_read(0x0810) -> 0x0000
    phy_write(0x0810) 0xffff
    phy_write(0x0810)
    Signed-off-by: John W. Linville

    Rafał Miłecki
     
  • John W. Linville
     

22 Jun, 2011

2 commits


21 Jun, 2011

18 commits


18 Jun, 2011

8 commits