Skip to content
Snippets Groups Projects
  1. Jul 12, 2010
  2. Jun 22, 2010
  3. Jun 03, 2010
  4. May 25, 2010
  5. May 14, 2010
    • Joe Perches's avatar
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      Joe Perches authored
      
      This patch removes from drivers/net/ all the unnecessary
      return; statements that precede the last closing brace of
      void functions.
      
      It does not remove the returns that are immediately
      preceded by a label as gcc doesn't like that.
      
      It also does not remove null void functions with return.
      
      Done via:
      $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
        xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'
      
      with some cleanups by hand.
      
      Compile tested x86 allmodconfig only.
      
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4b77097
  6. May 10, 2010
  7. Mar 15, 2010
  8. Jan 07, 2010
  9. Dec 03, 2009
  10. Nov 23, 2009
  11. Sep 11, 2009
    • Marcel Holtmann's avatar
      net: Add DEVTYPE support for Ethernet based devices · 384912ed
      Marcel Holtmann authored
      
      The Ethernet framing is used for a lot of devices these days. Most
      prominent are WiFi and WiMAX based devices. However for userspace
      application it is important to classify these devices correctly and
      not only see them as Ethernet devices. The daemons like HAL, DeviceKit
      or even NetworkManager with udev support tries to do the classification
      in userspace with a lot trickery and extra system calls. This is not
      good and actually reaches its limitations. Especially since the kernel
      does know the type of the Ethernet device it is pretty stupid.
      
      To solve this problem the underlying device type needs to be set and
      then the value will be exported as DEVTYPE via uevents and available
      within udev.
      
        # cat /sys/class/net/wlan0/uevent
        DEVTYPE=wlan
        INTERFACE=wlan0
        IFINDEX=5
      
      This is similar to subsystems like USB and SCSI that distinguish
      between hosts, devices, disks, partitions etc.
      
      The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
      device type. All device types are free form, but for convenience the
      same strings as used with RFKILL are choosen.
      
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      384912ed
  12. Sep 02, 2009
  13. Sep 01, 2009
  14. Jul 05, 2009
  15. Jun 13, 2009
  16. Jun 08, 2009
  17. Jun 03, 2009
    • Johannes Berg's avatar
      rfkill: rewrite · 19d337df
      Johannes Berg authored
      
      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: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      19d337df
  18. May 01, 2009
  19. Apr 22, 2009
  20. Apr 02, 2009
  21. Mar 21, 2009
  22. Feb 27, 2009
  23. Feb 17, 2009
    • Hannes Eder's avatar
      drivers/net/usb: fix sparse warnings: Should it be static? · 0227abc9
      Hannes Eder authored
      
      Impact: Make symbols static.
      
      Fix this sparse warnings:
        drivers/net/usb/hso.c:1249:6: warning: symbol 'hso_unthrottle_tasklet' was not declared. Should it be static?
        drivers/net/usb/hso.c:1268:6: warning: symbol 'hso_unthrottle_workfunc' was not declared. Should it be static?
        drivers/net/usb/hso.c:1466:5: warning: symbol 'tiocmget_submit_urb' was not declared. Should it be static?
        drivers/net/usb/smsc95xx.c:62:5: warning: symbol 'turbo_mode' was not declared. Should it be static?
      
      Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0227abc9
  24. Feb 03, 2009
    • Filip Aben's avatar
      hso: add new device id's · 67dd8246
      Filip Aben authored
      
      This patch adds a few device ID's. It also removes an ID that was used
      in an internal engineering version of a device and will never see
      commercial light. Even if this ID will be 'recycled' in the future,
      which is very unlikely, we don't know what kind of device will be
      behind it. Therefore it's safer to remove it.
      
      Signed-off-by: default avatarFilip Aben <f.aben@option.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67dd8246
  25. Feb 01, 2009
  26. Jan 15, 2009
  27. Jan 12, 2009
  28. Jan 02, 2009
Loading