1. 08 7月, 2014 23 次提交
  2. 06 7月, 2014 9 次提交
  3. 04 7月, 2014 1 次提交
  4. 03 7月, 2014 1 次提交
  5. 02 7月, 2014 6 次提交
    • R
      b43: add more bcma cores · 15be8e89
      Rafał Miłecki 提交于
      This adds some cores with 0x2057 radio which will be supported soon as
      well as core 40 that I missed in the earlier firmware patch.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      15be8e89
    • R
      b43: N-PHY: complete generic support for 0x2057 radio · fe255b40
      Rafał Miłecki 提交于
      It doesn't include any device (radio revision) specific code yet, so it
      isn't really usable. As the commit says, it's just some generic code.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fe255b40
    • R
      b43: N-PHY: fixes for radio 0x2057 · e90cf1c7
      Rafał Miłecki 提交于
      Enable initialization and update calibration code to fix:
      b43-phy0 ERROR: Radio 0x2057 rcal timeout
      b43-phy0 debug: Radio 0x2057 rccal timeout
      b43-phy0 debug: Radio 0x2057 rccal timeout
      b43-phy0 ERROR: Radio 0x2057 rcal timeout
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e90cf1c7
    • 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