1. 22 1月, 2013 2 次提交
    • S
      usb: gadget: composite: add usb_remove_function() · b4735778
      Sebastian Andrzej Siewior 提交于
      This will be used to remove a single function from a given config. Right
      now "ignore" that an error at ->bind() time and cleanup later during
      composite_unbind() / remove_config().
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b4735778
    • S
      usb: gadget: add some infracture to register/unregister functions · de53c254
      Sebastian Andrzej Siewior 提交于
      This patch provides an infrastructure to register & unregister a USB
      function. This allows to turn a function into a module and avoid the
      '#include "f_.*.c"' magic and we get a clear API / cut between the bare
      gadget and its functions.
      The concept is simple:
      Each function defines the DECLARE_USB_FUNCTION_INIT macro whith an unique
      name of the function and two allocation functions.
      - one to create an "instance". The instance holds the current configuration
        set. In case there are two usb_configudations with one function there will
        be one instance and two usb_functions
      - one to create an "function" from the instance.
      
      The name of the instance is used to automaticaly load the module if it the
      instance is not yet available.
      The usb_function callbacks are slightly modified and extended:
      - usb_get_function()
        creates a struct usb_function inclunding all pointers (bind,
        unbind,…). It uses the "instance" to map its configuration. So we can
        have _two_ struct usb_function, one for each usb_configuration.
      - ->unbind()
        Since the struct usb_function was not allocated in ->bind() it should
        not kfree()d here. This function should only reverse what happens in
        ->bind() that is request cleanup and the cleanup of allocated
        descriptors.
      - ->free_func()
        a simple kfree() of the struct usb_function
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      de53c254
  2. 10 1月, 2013 1 次提交
    • S
      usb: gadget: consider link speed for bMaxPower · 8f900a9a
      Sebastian Andrzej Siewior 提交于
      The USB 2.0 specification says that bMaxPower is the maximum power
      consumption expressed in 2 mA units and the USB 3.0 specification says
      that it is expressed in 8 mA units.
      
      This patch renames bMaxPower to MaxPower and the various /2 and *2 are
      removed. Before reporting the config descriptor, the proper value is
      computer based on the speed, all in-tree users are updated. MaxPower is
      also increased to u16 so we can store the nokia gadget value which is
      larger than the max value allowed for u8.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      8f900a9a
  3. 31 10月, 2012 2 次提交
  4. 10 9月, 2012 13 次提交
  5. 11 5月, 2012 2 次提交
  6. 02 7月, 2011 2 次提交
  7. 29 6月, 2011 2 次提交
  8. 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
  9. 31 3月, 2011 1 次提交
  10. 23 10月, 2010 3 次提交
  11. 24 8月, 2010 1 次提交
  12. 11 8月, 2010 2 次提交
  13. 21 5月, 2010 1 次提交
  14. 12 12月, 2009 1 次提交
  15. 16 6月, 2009 1 次提交
  16. 25 3月, 2009 1 次提交
  17. 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
  18. 26 7月, 2008 1 次提交
  19. 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