1. 10 9月, 2012 3 次提交
  2. 11 5月, 2012 2 次提交
  3. 02 7月, 2011 2 次提交
  4. 29 6月, 2011 2 次提交
  5. 11 5月, 2011 1 次提交
    • R
      usb: gadget: composite: Allow function drivers to pause control transfers · 1b9ba000
      Roger Quadros 提交于
      Some USB function drivers (e.g. f_mass_storage.c) need to delay or defer the
      data/status stages of standard control requests like SET_CONFIGURATION or
      SET_INTERFACE till they are done with their bookkeeping and are actually ready
      for accepting new commands to their interface.
      
      They can now achieve this functionality by returning USB_GADGET_DELAYED_STATUS
      in their setup handlers (e.g. set_alt()). The composite framework will then
      defer completion of the control transfer by not completing the data/status stages.
      
      This ensures that the host does not send new packets to the interface till the
      function driver is ready to take them.
      
      When the function driver that requested for USB_GADGET_DELAYED_STATUS is done
      with its bookkeeping, it should signal the composite framework to continue with
      the data/status stages of the control transfer. It can do so by invoking
      the new API usb_composite_setup_continue(). This is where the control transfer's
      data/status stages are completed and host can initiate new transfers.
      
      The DELAYED_STATUS mechanism is currently only supported if the expected data phase
      is 0 bytes (i.e. w_length == 0). Since SET_CONFIGURATION and SET_INTERFACE are the
      only cases that will use this mechanism, this is not a limitation.
      Signed-off-by: NRoger Quadros <roger.quadros@nokia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1b9ba000
  6. 31 3月, 2011 1 次提交
  7. 23 10月, 2010 3 次提交
  8. 24 8月, 2010 1 次提交
  9. 11 8月, 2010 2 次提交
  10. 21 5月, 2010 1 次提交
  11. 12 12月, 2009 1 次提交
  12. 16 6月, 2009 1 次提交
  13. 25 3月, 2009 1 次提交
  14. 18 10月, 2008 1 次提交
    • D
      usb gadget: function activation/deactivation · 60beed95
      David Brownell 提交于
      Add a new mechanism to the composite gadget framework, letting
      functions deactivate (and reactivate) themselves.  Think of it
      as a refcounted wrapper for the software pullup control.
      
      A key example of why to use this mechanism involves functions that
      require a userspace daemon.  Those functions shuld use this new
      mechanism to prevent the gadget from enumerating until those daemons
      are activated.  Without this mechanism, hosts would see devices that
      malfunction until the relevant daemons start.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      60beed95
  15. 26 7月, 2008 1 次提交
  16. 22 7月, 2008 1 次提交
    • D
      usb gadget: composite gadget core · 40982be5
      David Brownell 提交于
      Add <linux/usb/composite.h> interfaces for composite gadget drivers, and
      basic implementation support behind it:
      
        - struct usb_function ... groups one or more interfaces into a function
          managed as one unit within a configuration, to which it's added by
          usb_add_function().
      
        - struct usb_configuration ... groups one or more such functions into
          a configuration managed as one unit by a driver, to which it's added
          by usb_add_config().  These operate at either high or full/low speeds
          and at a given bMaxPower.
      
        - struct usb_composite_driver ... groups one or more such configurations
          into a gadget driver, which may be registered or unregistered.
      
        - struct usb_composite_dev ... a usb_composite_driver manages this; it
          wraps the usb_gadget exposed by the controller driver.
      
      This also includes some basic kerneldoc.
      
      How to use it (the short version):  provide a usb_composite_driver with a
      bind() that calls usb_add_config() for each of the needed configurations.
      The configurations in turn have bind() calls, which will usb_add_function()
      for each function required.  Each function's bind() allocates resources
      needed to perform its tasks, like endpoints; sometimes configurations will
      allocate resources too.
      
      Separate patches will convert most gadget drivers to this infrastructure.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      40982be5