1. 31 10月, 2016 1 次提交
    • F
      usb: add helper to extract bits 12:11 of wMaxPacketSize · 541b6fe6
      Felipe Balbi 提交于
      According to USB Specification 2.0 table 9-4,
      wMaxPacketSize is a bitfield. Endpoint's maxpacket
      is laid out in bits 10:0. For high-speed,
      high-bandwidth isochronous endpoints, bits 12:11
      contain a multiplier to tell us how many
      transactions we want to try per uframe.
      
      This means that if we want an isochronous endpoint
      to issue 3 transfers of 1024 bytes per uframe,
      wMaxPacketSize should contain the value:
      
      	1024 | (2 << 11)
      
      or 5120 (0x1400). In order to make Host and
      Peripheral controller drivers' life easier, we're
      adding a helper which returns bits 12:11. Note that
      no care is made WRT to checking endpoint type and
      gadget's speed. That's left for drivers to handle.
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      541b6fe6
  2. 25 8月, 2016 2 次提交
  3. 19 4月, 2016 3 次提交
  4. 29 3月, 2016 1 次提交
  5. 04 3月, 2016 2 次提交
  6. 15 2月, 2016 2 次提交
  7. 04 2月, 2016 3 次提交
  8. 25 1月, 2016 2 次提交
  9. 19 11月, 2015 1 次提交
    • L
      [media] uvcvideo: Enable UVC 1.5 device detection · 8afe97be
      Laurent Pinchart 提交于
      UVC 1.5 devices report a bInterfaceProtocol value set to 1 in their
      interface descriptors. The uvcvideo driver only matches on
      bInterfaceProtocol 0, preventing those devices from being detected.
      
      More changes to the driver are needed for full UVC 1.5 compatibility.
      However, at least the UVC 1.5 Microsoft Surface Pro 3 cameras have been
      reported to work out of the box with the driver with an updated match
      table.
      
      Enable UVC 1.5 support in the match table to support the devices that
      can work with the current driver implementation. Devices that can't will
      fail, but that's hardly a regression as they're currently not detected
      at all anyway.
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      8afe97be
  10. 04 10月, 2015 1 次提交
  11. 16 9月, 2015 1 次提交
  12. 29 7月, 2015 2 次提交
  13. 27 1月, 2015 1 次提交
  14. 16 9月, 2014 1 次提交
    • R
      usb: gadget: f_fs: virtual endpoint address mapping · 1b0bf88f
      Robert Baldyga 提交于
      This patch introduces virtual endpoint address mapping. It separates
      function logic form physical endpoint addresses making it more hardware
      independent.
      
      Following modifications changes user space API, so to enable them user
      have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors.
      
      Endpoints are now refered using virtual endpoint addresses chosen by
      user in endpoint descpriptors. This applies to each context when endpoint
      address can be used:
      - when accessing endpoint files in FunctionFS filesystemi (in file name),
      - in setup requests directed to specific endpoint (in wIndex field),
      - in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl.
      
      In endpoint file names the endpoint address number is formatted as
      double-digit hexadecimal value ("ep%02x") which has few advantages -
      it is easy to parse, allows to easly recognize endpoint direction basing
      on its name (IN endpoint number starts with digit 8, and OUT with 0)
      which can be useful for debugging purpose, and it makes easier to introduce
      further features allowing to use each endpoint number in both directions
      to have more endpoints available for function if hardware supports this
      (for example we could have ep01 which is endpoint 1 with OUT direction,
      and ep81 which is endpoint 1 with IN direction).
      
      Physical endpoint address can be still obtained using ioctl named
      FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle
      USB transactions properly.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Acked-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1b0bf88f
  15. 09 9月, 2014 1 次提交
  16. 02 9月, 2014 2 次提交
  17. 10 7月, 2014 1 次提交
  18. 27 6月, 2014 2 次提交
  19. 19 6月, 2014 1 次提交
  20. 28 5月, 2014 2 次提交
  21. 21 3月, 2014 1 次提交
  22. 06 3月, 2014 2 次提交
  23. 17 7月, 2013 1 次提交
  24. 09 4月, 2013 1 次提交
  25. 26 3月, 2013 1 次提交
    • B
      USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND · 3edce1cf
      Bjørn Mork 提交于
      Userspace applications need to know the maximum supported message
      size.
      
      The cdc-wdm driver translates between a character device stream
      and a message based protocol.  Each message is transported as a
      usb control message with no further encapsulation or syncronization.
      Each read or write on the character device should translate to
      exactly one usb control message to ensure that message boundaries
      are kept intact.  That means that the userspace application must
      know the maximum message size supported by the device and driver,
      making this size a vital part of the cdc-wdm character device API.
      
      CDC WDM and CDC MBIM functions export the maximum supported
      message size through CDC functional descriptors.  The cdc-wdm and
      cdc_mbim drivers will parse these descriptors and use the value
      chosen by the device.  The only current way for a userspace
      application to retrive the value is by duplicating the descriptor
      parsing. This is an unnecessary complex task, and application
      writers are likely to postpone it, using a fixed value and adding
      a "todo" item.
      
      QMI functions have no way to tell the host what message size they
      support.  The qmi_wwan driver use a fixed value based on protocol
      recommendations and observed device behaviour.  Userspace
      applications must know and hard code the same value.  This scheme
      will break if we ever encounter a QMI device needing a device
      specific message size quirk.  We are currently unable to support
      such a device because using a non default size would break the
      implicit userspace API.
      
      The message size is currently a hidden attribute of the cdc-wdm
      userspace API.  Retrieving it is unnecessarily complex, increasing
      the possibility of drivers and applications using different limits.
      The resulting errors are hard to debug, and can only be replicated
      on identical hardware.
      
      Exporting the maximum message size from the driver simplifies the
      task for the userspace application, and creates a unified
      information source independent of device and function class. It also
      serves to document that the message size is part of the cdc-wdm
      userspace API.
      
      This proposed API extension has been presented for the authors of
      userspace applications and libraries using the current API: libmbim,
      libqmi, uqmi, oFono and ModemManager.  The replies were:
      
      Aleksander Morgado:
       "We do really need max message size for MBIM; and as you say, it may be
        good to have the max message size info also for QMI, so the new ioctl
        seems a good addition. So +1 from my side, for what it's worth."
      
      Dan Williams:
       "Yeah, +1 here.  I'd prefer the sysfs file, but the fact that that
        doesn't work for fd passing pretty much kills it."
      
      No negative replies are so far received.
      
      Cc: Aleksander Morgado <aleksander@lanedo.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Acked-by: NOliver Neukum <oliver@neukum.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3edce1cf
  26. 21 2月, 2013 1 次提交
    • P
      ALSA: usb: Fix Processing Unit Descriptor parsers · b531f81b
      Pawel Moll 提交于
      Commit 99fc8645 "ALSA: usb-mixer:
      parse descriptors with structs" introduced a set of useful parsers
      for descriptors. Unfortunately the parses for the Processing Unit
      Descriptor came with a very subtle bug...
      
      Functions uac_processing_unit_iProcessing() and
      uac_processing_unit_specific() were indexing the baSourceID array
      forgetting the fields before the iProcessing and process-specific
      descriptors.
      
      The problem was observed with Sound Blaster Extigy mixer,
      where nNrModes in Up/Down-mix Processing Unit Descriptor
      was accessed at offset 10 of the descriptor (value 0)
      instead of offset 15 (value 7). In result the resulting
      control had interesting limit values:
      
      Simple mixer control 'Channel Routing Mode Select',0
        Capabilities: volume volume-joined penum
        Playback channels: Mono
        Capture channels: Mono
        Limits: 0 - -1
        Mono: -1 [100%]
      
      Fixed by starting from the bmControls, which was calculated
      correctly, instead of baSourceID.
      
      Now the mentioned control is fine:
      
      Simple mixer control 'Channel Routing Mode Select',0
        Capabilities: volume volume-joined penum
        Playback channels: Mono
        Capture channels: Mono
        Limits: 0 - 6
        Mono: 0 [0%]
      Signed-off-by: NPawel Moll <mail@pawelmoll.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b531f81b
  27. 25 1月, 2013 1 次提交
    • L
      usb: Using correct way to clear usb3.0 device's remote wakeup feature. · 54a3ac0c
      Lan Tianyu 提交于
      Usb3.0 device defines function remote wakeup which is only for interface
      recipient rather than device recipient. This is different with usb2.0 device's
      remote wakeup feature which is defined for device recipient. According usb3.0
      spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
      requests using the FUNCTION_SUSPEND feature selector. This patch is to use
      correct way to disable usb3.0 device's function remote wakeup after suspend
      error and resuming.
      
      This should be backported to kernels as old as 3.4, that contain the
      commit 623bef9e "USB/xhci: Enable remote
      wakeup for USB3 devices."
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      54a3ac0c