1. 13 6月, 2017 1 次提交
    • F
      usb: gadget: core: introduce ->udc_set_speed() method · 67fdfda4
      Felipe Balbi 提交于
      Sometimes, the gadget driver we want to run has max_speed lower than
      what the UDC supports. In such situations, UDC might want to make sure
      we don't try to connect on speeds not supported by the gadget
      driver (e.g. super-speed capable dwc3 with high-speed capable g_midi)
      because that will just fail.
      
      In order to make sure this situation never happens, we introduce a new
      optional ->udc_set_speed() method which can be implemented by
      interested UDC drivers.
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      67fdfda4
  2. 02 6月, 2017 1 次提交
  3. 17 5月, 2017 1 次提交
  4. 12 4月, 2017 3 次提交
  5. 11 4月, 2017 1 次提交
  6. 04 4月, 2017 1 次提交
    • G
      net: usbnet: support 64bit stats · c8b5d129
      Greg Ungerer 提交于
      Add support for the net stats64 counters to the usbnet core. With that
      in place put the hooks into every usbnet driver to use it.
      
      This is a strait forward addition of 64bit counters for RX and TX packet
      and byte counts. It is done in the same style as for the other net drivers
      that support stats64. Note that the other stats fields remain as 32bit
      sized values (error counts, etc).
      
      The motivation to add this is that it is not particularly difficult to
      get the RX and TX byte counts to wrap on 32bit platforms.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8b5d129
  7. 28 3月, 2017 2 次提交
  8. 23 3月, 2017 2 次提交
  9. 22 3月, 2017 2 次提交
  10. 21 3月, 2017 1 次提交
    • L
      usb/early: Add driver for xhci debug capability · aeb9dd1d
      Lu Baolu 提交于
      XHCI debug capability (DbC) is an optional but standalone
      functionality provided by an xHCI host controller. Software
      learns this capability by walking through the extended
      capability list of the host. XHCI specification describes
      DbC in section 7.6.
      
      This patch introduces the code to probe and initialize the
      debug capability hardware during early boot. With hardware
      initialized, the debug target (system on which this code is
      running) will present a debug device through the debug port
      (normally the first USB3 port). The debug device is fully
      compliant with the USB framework and provides the equivalent
      of a very high performance (USB3) full-duplex serial link
      between the debug host and target. The DbC functionality is
      independent of the xHCI host. There isn't any precondition
      from the xHCI host side for the DbC to work.
      
      One use for this feature is kernel debugging, for example
      when your machine crashes very early before the regular
      console code is initialized. Other uses include simpler,
      lockless logging instead of a full-blown printk console
      driver and klogd.
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linux-usb@vger.kernel.org
      Link: http://lkml.kernel.org/r/1490083293-3792-3-git-send-email-baolu.lu@linux.intel.com
      [ Small fix to the Kconfig help text. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      aeb9dd1d
  11. 17 3月, 2017 2 次提交
  12. 16 3月, 2017 3 次提交
  13. 14 3月, 2017 1 次提交
    • S
      usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk · 3243367b
      Samuel Thibault 提交于
      Some USB 2.0 devices erroneously report millisecond values in
      bInterval. The generic config code manages to catch most of them,
      but in some cases it's not completely enough.
      
      The case at stake here is a USB 2.0 braille device, which wants to
      announce 10ms and thus sets bInterval to 10, but with the USB 2.0
      computation that yields to 64ms.  It happens that one can type fast
      enough to reach this interval and get the device buffers overflown,
      leading to problematic latencies.  The generic config code does not
      catch this case because the 64ms is considered a sane enough value.
      
      This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
      to mark devices which actually report milliseconds in bInterval,
      and marks Vario Ultra devices as needing it.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3243367b
  14. 20 1月, 2017 4 次提交
  15. 09 12月, 2016 1 次提交
  16. 05 12月, 2016 1 次提交
    • T
      usb: hcd.h: construct hub class request constants from simpler constants · b9c2a2a3
      Tal Shorer 提交于
      Currently, each hub class request constant is defined by a line like:
      #define ClearHubFeature		(0x2000 | USB_REQ_CLEAR_FEATURE)
      
      The "magic" number for the high byte is one of 0x20, 0xa0, 0x23, 0xa3.
      The 0x80 bit that changes inditace USB_DIR_IN, and the 0x03 that
      pops up is the difference between USB_RECIP_DEVICE (0x00) and
      USB_RECIP_OTHER (0x03). The constant 0x20 bit is USB_TYPE_CLASS.
      
      This patch eliminates those magic numbers by defining a macro to help
      construct these hub class request from simpler constants.
      Note that USB_RT_HUB is defined as (USB_TYPE_CLASS | USB_RECIP_DEVICE)
      and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER).
      Signed-off-by: NTal Shorer <tal.shorer@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9c2a2a3
  17. 18 11月, 2016 1 次提交
  18. 31 8月, 2016 1 次提交
    • Y
      usb: gadget: add a new quirk to avoid skb_reserve in u_ether.c · 60e7396f
      Yoshihiro Shimoda 提交于
      Some platforms (e.g. USB-DMAC on R-Car SoCs) has memory alignment
      restriction. If memory alignment is not match, the usb peripheral
      driver decides not to use the DMA controller. Then, the performance
      is not good.
      
      In the case of u_ether.c, since it calls skb_reserve() in rx_submit(),
      it is possible to cause memory alignment mismatch.
      
      So, this patch adds a new quirk "quirk_avoids_skb_reserve" to avoid
      skb_reserve() calling in u_ether.c to improve performance.
      
      A peripheral driver will set this flag and network gadget drivers
      (e.g. f_ncm.c) will reference the flag via gadget_avoids_skb_reserve().
      Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      60e7396f
  19. 25 8月, 2016 2 次提交
  20. 27 6月, 2016 1 次提交
  21. 25 6月, 2016 1 次提交
  22. 21 6月, 2016 4 次提交
  23. 02 6月, 2016 1 次提交
    • T
      usb: musb: Return error value from musb_mailbox · 12b7db2b
      Tony Lindgren 提交于
      At least on n900 we have phy-twl4030-usb only generating cable
      interrupts, and then have a separate USB PHY.
      
      In order for musb to know the real cable status, we need to
      clear any cached state until musb is ready. Otherwise the cable
      status interrupts will get just ignored if the status does
      not change from the initial state.
      
      To do this, let's add a return value to musb_mailbox(), and
      reset cached linkstat to MUSB_UNKNOWN on error. Sorry to cause
      a bit of churn here, I should have added that already last time
      patching musb_mailbox().
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NBin Liu <b-liu@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12b7db2b
  24. 31 5月, 2016 1 次提交
  25. 29 4月, 2016 1 次提交
    • C
      usb: core: hub: hub_port_init lock controller instead of bus · feb26ac3
      Chris Bainbridge 提交于
      The XHCI controller presents two USB buses to the system - one for USB2
      and one for USB3. The hub init code (hub_port_init) is reentrant but
      only locks one bus per thread, leading to a race condition failure when
      two threads attempt to simultaneously initialise a USB2 and USB3 device:
      
      [    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
      [   13.183701] usb 3-3: device descriptor read/all, error -110
      
      On a test system this failure occurred on 6% of all boots.
      
      The call traces at the point of failure are:
      
      Call Trace:
       [<ffffffff81b9bab7>] schedule+0x37/0x90
       [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
       [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
       [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
       [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
       [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Call Trace:
       [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
       [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
       [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
       [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Which results from the two call chains:
      
      hub_port_init
       usb_get_device_descriptor
        usb_get_descriptor
         usb_control_msg
          usb_internal_control_msg
           usb_start_wait_urb
            usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
      
      hub_port_init
       hub_set_address
        xhci_address_device
         xhci_setup_device
      
      Mathias Nyman explains the current behaviour violates the XHCI spec:
      
       hub_port_reset() will end up moving the corresponding xhci device slot
       to default state.
      
       As hub_port_reset() is called several times in hub_port_init() it
       sounds reasonable that we could end up with two threads having their
       xhci device slots in default state at the same time, which according to
       xhci 4.5.3 specs still is a big no no:
      
       "Note: Software shall not transition more than one Device Slot to the
        Default State at a time"
      
       So both threads fail at their next task after this.
       One fails to read the descriptor, and the other fails addressing the
       device.
      
      Fix this in hub_port_init by locking the USB controller (instead of an
      individual bus) to prevent simultaneous initialisation of both buses.
      
      Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel")
      Link: https://lkml.org/lkml/2016/2/8/312
      Link: https://lkml.org/lkml/2016/2/4/748Signed-off-by: NChris Bainbridge <chris.bainbridge@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      feb26ac3