1. 02 7月, 2014 7 次提交
    • A
      rtl818x_pci: fix pci probe returns success when it fails · c1084e02
      Andrea Merello 提交于
      There are several exit path from the PCI probe function.
      Some of them, that are taken in case of errors, forget to set the "err"
      variable, that is returned by the probe function.
      This can lead to the kernel thinking the probe function succeeds while it
      didn't, and this in turn causes extra calls to the "remove" function.
      
      This patch fix this problem by ensuring "err" variable is assigned to a proper
      non-zero value in each exit path.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c1084e02
    • A
      rtl818x_pci: handle broken PIO mapping · f4cf6287
      Andrea Merello 提交于
      All boards supported by this driver could work using PIO or MMIO for accessing
      registers.
      This driver tries to access HW by using MMIO, and, if this fails for somewhat
      reason, the driver tries to fall back to PIO mode.
      
      MMIO-mode is straightforward on all boards.
      PIO-mode is straightforward on rtl8180 only.
      
      On rtl8185 and rtl8187se boards not all registers are directly available in PIO
      mode (they are paged).
      
      On rtl8185 there are two pages and it is known how to switch page.
      PIO mode works, except for only one access to a register out of default page,
      recently added by me in the initialization code with patch:
      rtl818x_pci: Fix rtl8185 excessive IFS after CTS-to-self
      This can be easily fixed to work in both cases (MMIO and PIO).
      
      On rtl8187se, for a number of reasons, there is much more work to do to fix PIO
      access.
      PIO access is currently broken on rtl8187se, and it never worked.
      
      This patch fixes the said register write for rtl8185 and makes the driver to
      fail cleanly if PIO mode is attempted with rtl8187se boards.
      
      While doing this, I converted also a couple of printk(KERN_ERR) to dev_err(), in
      order to make checkpatch happy.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f4cf6287
    • A
      rtl8180: disable buggy rate fallback mechanism · fe67bcd4
      Andrea Merello 提交于
      Currently the driver configures mac80211 to provide two rates for each TX frame:
      One initial rate and one alternate fallback rate, each one with its retry count.
      
      HW does not support fully this: rtl8180 doesn't have support for rate scaling at
      all, and rtl8185/rtl8187SE supports it in a way that does not fit with mac80211:
      The HW does automatically fall back to the next lower rate, and only a lower
      limit can be specified, so the HW may TX also on rates in between the two rates
      specified by mac80211.  Furthermore only the total TX retry count can be
      specified for each packet, while the number of TX attempts before scaling rate
      can be configured only globally (not per each packet).
      
      Currently the driver sets the HW auto rate fallback mechanism to quickly scale
      rate after a couple of retries, and it uses the alternate rate requested by
      mac80211 as fallback limit rate (and it does this even wrongly).
      
      The HW indeed will behave differently than what mac80211 mandates, that is
      probably undesirable, and the reported TX retry count may not refer to what
      mac80211 thinks, and this could fool mac80211.
      
      This patch makes the driver to declare to mac80211 to support only one rate
      configuration for each packet, and it does disable the HW auto rate fallback
      mechanism, relying only on SW and letting mac80211 to do all by itself.
      
      This should ensure correct operation and fairness respect to mac80211.
      Indeed here tests with iperf do not show significant performance differences.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fe67bcd4
    • A
      rtl8180: fix incorrect TX retry. · 81129fce
      Andrea Merello 提交于
      HW is programmed with wrong retry count value for TX:
      
      Mac80211 passes to driver the number of times the TX should be attempted.
      The HW, instead, wants the number of time the TX should be retried if it fails
      the first time (assuming we have to TX it at least one time).
      
      This patch correct this.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      81129fce
    • A
      rtl818x_pci: add comment pointing to the rtl8187se reference code · f82be7c4
      Andrea Merello 提交于
      Rtl8187se support has been added to the rtl818x_pci driver by extracting a lot
      of information from a rtl8187se Linux staging driver included in the kernel at
      the time rtl8187se support was added.
      The rtl818x_pci main file has a comment that advertises this.
      
      Recently this staging driver has been removed from the kernel, but I still feel
      it can be useful as "reference" code (in case of bugs, or to implement
      improvements in rtl818x_pci driver).
      
      This one-line patch adds a comment in rtl818x_pci driver to point people
      searching for that "reference code" to the last kernel version still containing
      it (3.14).
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f82be7c4
    • A
      rtl818x_pci: Fix rtl8185 excessive IFS after CTS-to-self · 7df00724
      Andrea Merello 提交于
      Measuring time between _end_ of CTS-to-self and _end_ of datapacket (with a
      prism54 board and mac80211 hacked to let the MAC timestamp stay untouched in the
      radiotap header) resulted in about 300uS, while the datapacket itself should be
      by far shorter (less than 100uS) and IFS should be SIFS (10uS).
      This measure was confirmed whith a scope: about 250uS IFS has been seen between
      the two packets.
      
      This situation causes the CTS-to-self protection mechanism to work incorrectly
      due to the NAV expiring during, or even before beginning, the packet
      transmission, and it also causes the performances to be anyway reduced due to
      time waste.
      
      This problem has been seen at every packet TXed with CTS-to-self enabled on
      rtl8185 board.
      rtl8187se seems not affected (and rtl8180, being a 802.11b card, does not have
      CTS-to-self mechaninsm).
      
      This patch fixes this by adding a magic register write, making the board wait
      for correct SIFS after CTS-to-self packet.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7df00724
    • A
      rtl818x_pci: Fix BSSID register written incorrectly · 1f622d76
      Andrea Merello 提交于
      BSSID register was written with six byte-writes.
      It seems that, similarly to what happens with MAC registers, they needs to be
      written with one 16-bit and one 32-bit writes, otherwise the write does not work.
      
      The byte write didn't work only on my rtl8185, while it worked on rtl8180 and
      rtl8187se, BTW since there are probably a number of different ASIC revisions out
      of there, I let the change to affect all cards.
      It shouldn't hurt anyway.
      Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1f622d76
  2. 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
  3. 08 5月, 2014 2 次提交
  4. 23 4月, 2014 2 次提交
  5. 28 3月, 2014 18 次提交
  6. 18 3月, 2014 3 次提交
  7. 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
  8. 05 3月, 2014 2 次提交
  9. 01 3月, 2014 2 次提交