1. 20 6月, 2014 3 次提交
    • A
      rtl818x_pci: fix possible RX descriptor invalid data read · 325ed9ff
      Andrea Merello 提交于
      RX descriptor data must be read only if the descriptor has been fully
      updated by HW.
      There is a "ownership" flag in the descriptor itself to test this.
      
      The driver code contains a read for the "ownership" flag and, after
      it, other read access for descriptor data.
      
      This is in DMA coherent memory, that is _not_ guaranteed to be immune
      to instruction reordering, thus it is possible that the descriptor
      data is read _before_ the "ownership" flag.
      
      This can theoretically lead to a DMA/CPU race that may end up with the
      driver reading the data when it is still not valid, and the "ownership"
      bit just after enough time that the HW make the whole descriptor valid.
      The driver will in this case believe the data is valid, but it will use
      the invalid data read earlier.
      
      In order to avoid this, this patch adds a rmb() to force the "ownership"
      bit read to be issued before other descriptor data reads are attempted.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      325ed9ff
    • A
      rtl818x_pci: provide dBm signal information for rtl8185 · 7049327a
      Andrea Merello 提交于
      This patch makes the driver report signal information for rtl8185
      boards using dBm instead of unspecified unit.
      Rtl8180 remains untouched.
      
      I did some tests to confirm the correctness of the measure performed
      by the board and it seems reasonably correct.
      
      The test setup has been made by connecting an AP with coax and
      RF attenuators to the card antenna port.
      
      In order to get a reference measure I tried with several cards with
      different chipset I own. I found that many gave different results, and
      I finally selected two cards that gave me consistent results to use
      as reference: AR9271 and Prism54-usb (isl3887 with Frisbee radio).
      
      Using this references I compared the RSSI information with my rtl8185
      and I repeated tests with three different attenuation values, increasing
      attenuation by 10dB each step.
      I made only relative measures, making NO assumption about source power.
      
      CCK measures seem very close to my references, OFDM are a little bit
      less precise but, considering that these cards are not measuring
      instrumentation, IMHO this is still fairly good.
      
      CCK measures (1Mbps beacons)
      
       ATTENUATOR 1
      p54usb:    -58dBm
      ath9k_htc: -59dBm
      rtl8185:   -59dBm
      
       ATTENUATOR 2
      p54usb:    -67dBm
      ath9k_htc: -68dBm
      rtl8185:   -70dBm
      
       ATTENUATOR 3
      p54usb:    -78dBm
      ath9k_htc: -79dBm
      rtl8185:   -79dBm
      
      OFDM measures (54Mbps ping)
      
       ATTENUATOR 1
      p54usb:    -58dBm
      ath9k_htc: -57dBm
      rtl8185:   -62dBm
      
       ATTENUATOR 2
      p54usb:    -68dBm
      rtl8185:   -71dBm
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7049327a
    • A
      rtl818x_pci: make RSSI code more readable · afbedbf7
      Andrea Merello 提交于
      remove the if-else chains and use switch-case to make code more
      readable and avoiding long lines that broke in several lines
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afbedbf7
  2. 08 5月, 2014 2 次提交
  3. 23 4月, 2014 2 次提交
  4. 28 3月, 2014 18 次提交
  5. 18 3月, 2014 3 次提交
  6. 15 3月, 2014 1 次提交
    • A
      rtl8180: prepare to handle more than two chip types · 6caefd12
      Andrea Merello 提交于
      Currently a "r8185" integer variable is used as a boolean flag to
      indicate whether the card is a rtl8185 or not.
      Since now the driver supports only rtl8185 and rtl8180 cards, if
      "r8185" variable is zero then the card is implicitly assumed to
      be a rtl8180.
      
      Now I'm preparing to add support for a third card type (rtl8187se).
      
      This patch changes the "r8185" flag with an enum variable to
      explicitly indicate which card type we have.
      
      I'm submitting this this patch now, even if I still have to submit
      other patches that not pertain with rtl8187se support, because
      IMHO it's not worth rebasing them on the current code, using r8185
      flag, and then changing them back again nearly immediately.
      BTW if someone feels I really should do this, please tell me..
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6caefd12
  7. 05 3月, 2014 2 次提交
  8. 01 3月, 2014 5 次提交
  9. 13 2月, 2014 1 次提交
  10. 07 2月, 2014 2 次提交
    • A
      rtl8180: Add error check for pci_map_single return value in TX path · 348f7d4a
      andrea.merello 提交于
      Orignal code will not detect a DMA mapping failure, causing the HW
      to attempt a DMA from an invalid address.
      
      This patch add the error check and eventually simply drops the TX
      packet if we can't map it for DMA.
      Signed-off-by: Nandrea merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      348f7d4a
    • A
      rtl8180: Add error check for pci_map_single return value in RX path · 2b4db05e
      andrea.merello 提交于
      In original code the old RX DMA buffer is unmapped and processed and at the end
      of the isr a new buffer is mapped with pci_map_single and attached to the RX
      descriptor.
      
      If pci_map_single fails then the RX descriptor remains with no valid DMA buffer
      attached.
      In this condition the DMA will target where it shouldn't with obvious evil
      consequences.
      
      Simply avoiding re-arming the descriptor will prevent buggy DMA but it will
      result soon in RX stuck.
      
      This patch move the DMA mapping of the new buffer at the beginning of the ISR
      (and it adds error check for pci_map_single success/fail).
      
      If the DMA mapping fails then we do not unmap the old buffer and we re-arm the
      descriptor without processing it, with the old DMA buffer still attached.
      
      In this way we lose the currently RX-ed packet, but whenever next calls to
      pci_map_single will succeed again,then the RX process will go on without stuck.
      Signed-off-by: Nandrea merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2b4db05e
  11. 04 1月, 2014 1 次提交