1. 23 9月, 2009 1 次提交
  2. 17 9月, 2009 1 次提交
  3. 11 7月, 2009 2 次提交
  4. 04 6月, 2009 1 次提交
  5. 07 5月, 2009 3 次提交
  6. 16 4月, 2009 1 次提交
  7. 17 3月, 2009 2 次提交
  8. 30 1月, 2009 3 次提交
  9. 24 1月, 2009 1 次提交
  10. 23 1月, 2009 1 次提交
  11. 13 1月, 2009 2 次提交
  12. 20 12月, 2008 2 次提交
  13. 13 12月, 2008 1 次提交
  14. 05 12月, 2008 2 次提交
  15. 11 11月, 2008 1 次提交
  16. 01 11月, 2008 2 次提交
  17. 28 10月, 2008 1 次提交
  18. 15 10月, 2008 1 次提交
  19. 01 10月, 2008 1 次提交
    • L
      p54: Fix sparse warnings · 1f1c0e33
      Larry Finger 提交于
      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: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1f1c0e33
  20. 06 9月, 2008 3 次提交
  21. 23 8月, 2008 1 次提交
  22. 18 8月, 2008 1 次提交
    • C
      p54u: reset skb's data/tail pointer on requeue · d47c3ceb
      Christian Lamparter 提交于
      (Only important for USB V1 Adaptors)
      
      If an incoming frame wasn't accepted by p54_rx function
      the skb will be reused for new frames...
      
      But, we must not forget to set the skb's data pointers into
      the same state in which it was initialized by p54u_init_urbs.
      
      Otherwise we either end up with 16 bytes less on every requeue,
      or if a new frame is worthy enough to be accepted, the data is
      in the wrong place (urb->transfer_buffer wasn't updated!) and mac80211
      has a hard time to recognize it...
      Signed-off-by: NChristian Lamparter <chunkeey@web.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d47c3ceb
  23. 10 7月, 2008 1 次提交
  24. 05 6月, 2008 1 次提交
  25. 09 4月, 2008 1 次提交
  26. 14 3月, 2008 1 次提交
  27. 21 2月, 2008 2 次提交