1. 16 3月, 2010 1 次提交
  2. 07 1月, 2010 6 次提交
  3. 04 12月, 2009 1 次提交
  4. 24 11月, 2009 2 次提交
  5. 12 9月, 2009 1 次提交
    • M
      net: Add DEVTYPE support for Ethernet based devices · 384912ed
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      384912ed
  6. 02 9月, 2009 1 次提交
  7. 01 9月, 2009 1 次提交
  8. 06 7月, 2009 1 次提交
  9. 13 6月, 2009 1 次提交
  10. 08 6月, 2009 1 次提交
  11. 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
  12. 02 5月, 2009 1 次提交
  13. 23 4月, 2009 1 次提交
  14. 03 4月, 2009 2 次提交
  15. 02 4月, 2009 1 次提交
  16. 22 3月, 2009 1 次提交
  17. 27 2月, 2009 2 次提交
  18. 18 2月, 2009 1 次提交
    • H
      drivers/net/usb: fix sparse warnings: Should it be static? · 0227abc9
      Hannes Eder 提交于
      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: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0227abc9
  19. 04 2月, 2009 1 次提交
    • F
      hso: add new device id's · 67dd8246
      Filip Aben 提交于
      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: NFilip Aben <f.aben@option.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67dd8246
  20. 01 2月, 2009 1 次提交
  21. 16 1月, 2009 3 次提交
  22. 13 1月, 2009 1 次提交
  23. 03 1月, 2009 5 次提交
  24. 30 12月, 2008 1 次提交
    • J
      drivers/net/usb: use USB API functions rather than constants · f201a8a4
      Julia Lawall 提交于
      This set of patches introduces calls to the following set of functions:
      
      usb_endpoint_dir_in(epd)
      usb_endpoint_dir_out(epd)
      usb_endpoint_is_bulk_in(epd)
      usb_endpoint_is_bulk_out(epd)
      usb_endpoint_is_int_in(epd)
      usb_endpoint_is_int_out(epd)
      usb_endpoint_num(epd)
      usb_endpoint_type(epd)
      usb_endpoint_xfer_bulk(epd)
      usb_endpoint_xfer_control(epd)
      usb_endpoint_xfer_int(epd)
      usb_endpoint_xfer_isoc(epd)
      
      In some cases, introducing one of these functions is not possible, and it
      just replaces an explicit integer value by one of the following constants:
      
      USB_ENDPOINT_XFER_BULK
      USB_ENDPOINT_XFER_CONTROL
      USB_ENDPOINT_XFER_INT
      USB_ENDPOINT_XFER_ISOC
      
      In drivers/net/wireless/zd1211rw/zd_usb.c the code:
      
      (endpoint->bEndpointAddress & USB_TYPE_MASK) == USB_DIR_OUT
      
      is suspicious.  If it is intended to use USB_ENDPOINT_DIR_MASK rather than
      USB_TYPE_MASK, then the whole conditional test could be converted to a call
      to usb_endpoint_is_bulk_in.
      
      An extract of the semantic patch that makes these changes is as follows:
      (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      @r1@ struct usb_endpoint_descriptor *epd; @@
      
      - ((epd->bmAttributes & \(USB_ENDPOINT_XFERTYPE_MASK\|3\)) ==
      - \(USB_ENDPOINT_XFER_CONTROL\|0\))
      + usb_endpoint_xfer_control(epd)
      
      @r5@ struct usb_endpoint_descriptor *epd; @@
      
      - ((epd->bEndpointAddress & \(USB_ENDPOINT_DIR_MASK\|0x80\)) ==
      -  \(USB_DIR_IN\|0x80\))
      + usb_endpoint_dir_in(epd)
      
      @inc@
      @@
      
      #include <linux/usb.h>
      
      @depends on !inc && (r1||r5)@
      @@
      
      + #include <linux/usb.h>
        #include <linux/usb/...>
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f201a8a4
  25. 23 12月, 2008 1 次提交
  26. 25 11月, 2008 1 次提交