1. 16 Mar, 2009 1 commit
  2. 29 Jan, 2009 7 commits
  3. 19 Dec, 2008 3 commits
  4. 05 Dec, 2008 2 commits
  5. 25 Nov, 2008 1 commit
  6. 10 Nov, 2008 1 commit
  7. 31 Oct, 2008 4 commits
  8. 30 Sep, 2008 1 commit
    • Larry Finger's avatar
      p54: Fix sparse warnings · 1f1c0e33
      Larry Finger authored
      
      
      The command
      
      make C=2 CF="-D__CHECK_ENDIAN__" drivers/net/wireless/p54/
      
      generates the following warnings:
      
      .../p54common.c:152:38: warning: incorrect type in argument 1 (different base types)
      .../p54common.c:152:38:    expected restricted __be32 const [usertype] *p
      .../p54common.c:152:38:    got unsigned int *<noident>
      .../p54common.c:184:15: warning: restricted __le32 degrades to integer
      .../p54common.c:185:29: warning: cast to restricted __le16
      .../p54common.c:309:11: warning: symbol 'p54_rf_chips' was not declared.
      		        Should it be static?
      .../p54common.c:313:5: warning: symbol 'p54_parse_eeprom' was not declared.
      		       Should it be static?
      .../p54common.c:620:43: warning: incorrect type in argument 3 (different base types)
      .../p54common.c:620:43:    expected unsigned long [unsigned] [usertype] len
      .../p54common.c:620:43:    got restricted __le16 [usertype] len
      .../p54common.c:780:41: warning: restricted __le16 degrades to integer
      .../p54common.c:781:32: warning: restricted __le16 degrades to integer
      .../p54common.c:1250:28: warning: incorrect type in argument 2 (different base types)
      .../p54common.c:1250:28:    expected unsigned short [unsigned] [usertype] filter_type
      .../p54common.c:1250:28:    got restricted __le16 [usertype] filter_type
      .../p54common.c:1252:28: warning: incorrect type in argument 2 (different base types)
      .../p54common.c:1252:28:    expected unsigned short [unsigned] [usertype] filter_type
      .../p54common.c:1252:28:    got restricted __le16 [usertype] filter_type
      .../p54common.c:1257:42: warning: incorrect type in argument 2 (different base types)
      .../p54common.c:1257:42:    expected unsigned short [unsigned] [usertype] filter_type
      .../p54common.c:1257:42:    got restricted __le16
      .../p54common.c:1260:42: warning: incorrect type in argument 2 (different base types)
      .../p54common.c:1260:42:    expected unsigned short [unsigned] [usertype] filter_type
      .../p54common.c:1260:42:    got restricted __le16
      .../p54usb.c:228:10: warning: restricted __le32 degrades to integer
      .../p54usb.c:228:23: warning: restricted __le32 degrades to integer
      .../p54usb.c:228:7: warning: incorrect type in assignment (different base types)
      .../p54usb.c:228:7:    expected restricted __le32 [assigned] [usertype] chk
      .../p54usb.c:228:7:    got unsigned int
      .../p54usb.c:221:8: warning: symbol 'p54u_lm87_chksum' was not declared.
      		    Should it be static?
      
      All of the above have been fixed. One question, however, remains: In struct
      bootrec, the array "data" is treated in many places as native CPU order, but
      it may be little-endian everywhere. As far as I can tell, this driver has only
      been used with little-endian hardware.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1f1c0e33
  9. 11 Sep, 2008 3 commits
  10. 08 Sep, 2008 2 commits
  11. 05 Sep, 2008 2 commits
  12. 29 Aug, 2008 1 commit
  13. 22 Aug, 2008 1 commit
  14. 18 Aug, 2008 1 commit
  15. 21 May, 2008 1 commit
  16. 08 Apr, 2008 1 commit
  17. 04 Mar, 2008 1 commit
  18. 29 Feb, 2008 1 commit
    • Johannes Berg's avatar
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg authored
      
      
      This patch creates new cfg80211 wiphy API for channel and bitrate
      registration and converts mac80211 and drivers to the new API. The
      old mac80211 API is completely ripped out. All drivers (except ath5k)
      are updated to the new API, in many cases I expect that optimisations
      can be done.
      
      Along with the regulatory code I've also ripped out the
      IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
      unnecessary if the hardware simply gives us whatever channels it wants
      to support and we then enable/disable them as required, which is pretty
      much required for travelling.
      
      Additionally, the patch adds proper "basic" rate handling for STA
      mode interface, AP mode interface will have to have new API added
      to allow userspace to set the basic rate set, currently it'll be
      empty... However, the basic rate handling will need to be moved to
      the BSS conf stuff.
      
      I do expect there to be bugs in this, especially wrt. transmit
      power handling where I'm basically clueless about how it should work.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  19. 10 Oct, 2007 1 commit