Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 6月, 2014 6 次提交
  3. 30 5月, 2014 1 次提交
  5. 20 5月, 2014 3 次提交
  7. 01 5月, 2014 1 次提交
  9. 25 2月, 2014 1 次提交
  11. 07 8月, 2012 2 次提交
  13. 20 12月, 2011 1 次提交
  15. 23 8月, 2011 1 次提交
  17. 08 7月, 2011 1 次提交
  19. 07 7月, 2011 1 次提交
  21. 18 6月, 2011 1 次提交
  23. 02 6月, 2011 2 次提交
  25. 17 5月, 2011 1 次提交
  27. 09 12月, 2010 3 次提交
  29. 23 11月, 2010 1 次提交
  31. 07 10月, 2010 1 次提交
  33. 26 1月, 2010 2 次提交
  35. 09 9月, 2009 1 次提交
  37. 29 8月, 2009 1 次提交
    • G
      b43: Fix and update LP-PHY code · 68ec5329
      由 Gábor Stefanik 提交于 
      -Fix a few nasty typos (b43_phy_* operations instead of b43_radio_*)
 in the channel tune routines.
-Fix some typos & spec errors found by MMIO tracing.
-Optimize b43_phy_write & b43_phy_mask/set/maskset to use
 only the minimal number of MMIO accesses. (Write is possible
 using a single 32-bit MMIO write, while set/mask/maskset can
 be done in 3 16-bit MMIOs).
-Set the default channel back to 1, as the bug forcing us to use
 channel 7 is now fixed.

With this, the device comes up, scans, associates, transmits,
receives, monitors and injects on all channels - in other words,
it's fully functional. Sensitivity and TX power are still sub-optimal,
due to the lack of calibration (that's next on my list).
Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      68ec5329
  39. 05 8月, 2009 2 次提交
    • G
      b43: implement baseband init for LP-PHY <= rev1 · 738f0f43
      由 Gábor Stefanik 提交于 
      Implement baseband init for rev.0 and rev.1 LP PHYs. Convert boardflags_hi values to defines.
Implement b43_phy_copy for easier copying between registers, as needed by LP-PHY init.

Signed-off-by: Gábor Stefanik<netrolller.3d@gmail.com>
Cc: Michael Buesch<mb@bu3sch.de>
Cc: Larry Finger<larry.finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      738f0f43
    • L
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      由 Luis R. Rodriguez 提交于 
      The mac80211 workqueue exists to enable mac80211 and drivers
to queue their own work on a single threaded workqueue. mac80211
takes care to flush the workqueue during suspend but we never
really had requirements on drivers for how they should use
the workqueue in consideration for suspend.

We extend mac80211 to document how the mac80211 workqueue should
be used, how it should not be used and finally move raw access to
the workqueue to mac80211 only. Drivers and mac80211 use helpers
to queue work onto the mac80211 workqueue:

  * ieee80211_queue_work()
  * ieee80211_queue_delayed_work()

These helpers will now warn if mac80211 already completed its
suspend cycle and someone is trying to queue work. mac80211
flushes the mac80211 workqueue prior to suspend a few times,
but we haven't taken the care to ensure drivers won't add more
work after suspend. To help with this we add a warning when
someone tries to add work and mac80211 already completed the
suspend cycle.

Drivers should ensure they cancel any work or delayed work
in the mac80211 stop() callback.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42935eca
  41. 04 6月, 2009 1 次提交
    • J
      rfkill: rewrite · 19d337df
      由 Johannes Berg 提交于 
      This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19d337df
  43. 16 4月, 2009 1 次提交
  45. 20 12月, 2008 2 次提交
  47. 16 9月, 2008 1 次提交
  49. 09 9月, 2008 1 次提交
  51. 06 9月, 2008 1 次提交