Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 14
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 10月, 2017 2 次提交
  3. 17 10月, 2017 14 次提交
    • F
      usb: quirks: add quirk for WORLDE MINI MIDI keyboard · 2811501e
      由 Felipe Balbi 提交于 
      This keyboard doesn't implement Get String descriptors properly even
though string indexes are valid. What happens is that when requesting
for the String descriptor, the device disconnects and
reconnects. Without this quirk, this loop will continue forever.

Cc: Alan Stern <stern@rowland.harvard.edu>
Reported-by: NВладимир Мартьянов <vilgeforce@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2811501e
    • J
      usb: musb: sunxi: Explicitly release USB PHY on exit · 6ed05c68
      由 Jonathan Liu 提交于 
      This fixes a kernel oops when unloading the driver due to usb_put_phy
being called after usb_phy_generic_unregister when the device is
detached. Calling usb_phy_generic_unregister causes x->dev->driver to
be NULL in usb_put_phy and results in a NULL pointer dereference.

Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: NJonathan Liu <net147@gmail.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ed05c68
    • J
      usb: musb: Check for host-mode using is_host_active() on reset interrupt · 445ef615
      由 Jonathan Liu 提交于 
      The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect IRQ. When this
happens the musb controller switches from host mode to device mode
(it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
MUSB_DEVCTL_BDEVICE) and gets stuck in this state.

The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
was cleared.

To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
to detect babble error so that sunxi musb babble recovery can handle it
by restoring the mode. This information is provided by the driver logic
and does not rely on register contents.

Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: NJonathan Liu <net147@gmail.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      445ef615
    • A
      usb: musb: musb_cppi41: Configure the number of channels for DA8xx · 297d7fe9
      由 Alexandre Bailon 提交于 
      Currently, the number of channels is set to 15 but in the case of DA8xx,
the number of channels is 4.
Update the driver to configure the number of channels at runtime.

Cc: stable@vger.kernel.org  # v4.12+
Signed-off-by: NAlexandre Bailon <abailon@baylibre.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      297d7fe9
    • A
      usb: musb: musb_cppi41: Fix cppi41_set_dma_mode() for DA8xx · e10c5b0c
      由 Alexandre Bailon 提交于 
      The way to configure the DMA mode on DA8xx is different from DSPS.
Add a new function to configure DMA mode on DA8xx and use a callback
to call the right function based on the platform.

Cc: stable@vger.kernel.org  # v4.12+
Signed-off-by: NAlexandre Bailon <abailon@baylibre.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e10c5b0c
    • A
      usb: musb: musb_cppi41: Fix the address of teardown and autoreq registers · bfa53e0e
      由 Alexandre Bailon 提交于 
      The DA8xx and DSPS platforms don't use the same address for few registers.
On Da8xx, this is causing some issues (e.g. teardown that doesn't work).
Configure the address of the register during the init and use them instead
of constants.

Cc: stable@vger.kernel.org  # v4.12+
Reported-by: nsekhar@ti.com
Signed-off-by: NAlexandre Bailon <abailon@baylibre.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfa53e0e
    • J
      USB: musb: fix late external abort on suspend · 0c3aae9b
      由 Johan Hovold 提交于 
      The musb delayed irq work was never flushed on suspend, something which
since 4.9 can lead to an external abort if the work is scheduled after
the grandparent's clock has been disabled:

PM: Suspending system (mem)
PM: suspend of devices complete after 125.224 msecs
PM: suspend devices took 0.132 seconds
PM: late suspend of devices complete after 7.423 msecs
PM: noirq suspend of devices complete after 7.083 msecs
suspend debug: Waiting for 5 second(s).
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0262c60
...
[<c054880c>] (musb_default_readb) from [<c0547b5c>] (musb_irq_work+0x48/0x220)
[<c0547b5c>] (musb_irq_work) from [<c014f8a4>] (process_one_work+0x1f4/0x758)
[<c014f8a4>] (process_one_work) from [<c014fe5c>] (worker_thread+0x54/0x514)
[<c014fe5c>] (worker_thread) from [<c015704c>] (kthread+0x128/0x158)
[<c015704c>] (kthread) from [<c0109330>] (ret_from_fork+0x14/0x24)

Commit 2bff3916 ("usb: musb: Fix PM for hub disconnect") started
scheduling musb_irq_work with a delay of up to a second and with
retries thereby making this easy to trigger, for example, by suspending
shortly after a disconnect.

Note that we set a flag to prevent the irq work from rescheduling itself
during suspend and instead process a disconnect immediately. This takes
care of the case where we are disconnected shortly before suspending.

However, when in host mode, a disconnect while suspended will still
go unnoticed and thus prevent the controller from runtime suspending
upon resume as the session bit is always set. This will need to be
addressed separately.

Fixes: 550a7375 ("USB: Add MUSB and TUSB support")
Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core")
Fixes: 2bff3916 ("usb: musb: Fix PM for hub disconnect")
Cc: stable <stable@vger.kernel.org>     # 4.9
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c3aae9b
    • J
      USB: musb: fix session-bit runtime-PM quirk · 4f190e0b
      由 Johan Hovold 提交于 
      The current session-bit quirk implementation does not prevent the retry
counter from underflowing, something which could break runtime PM and
keep the device active for a very long time (about 2^32 seconds) after a
disconnect.

This notably breaks the B-device timeout case, but could potentially
cause problems also when the controller is operating as an A-device.

Fixes: 2bff3916 ("usb: musb: Fix PM for hub disconnect")
Cc: stable <stable@vger.kernel.org>     # 4.9
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f190e0b
    • M
      usb: cdc_acm: Add quirk for Elatec TWN3 · 765fb2f1
      由 Maksim Salau 提交于 
      Elatec TWN3 has the union descriptor on data interface. This results in
failure to bind the device to the driver with the following log:
  usb 1-1.2: new full speed USB device using streamplug-ehci and address 4
  usb 1-1.2: New USB device found, idVendor=09d8, idProduct=0320
  usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
  usb 1-1.2: Product: RFID Device (COM)
  usb 1-1.2: Manufacturer: OEM
  cdc_acm 1-1.2:1.0: Zero length descriptor references
  cdc_acm: probe of 1-1.2:1.0 failed with error -22

Adding the NO_UNION_NORMAL quirk for the device fixes the issue.

`lsusb -v` of the device:

Bus 001 Device 003: ID 09d8:0320
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        32
  idVendor           0x09d8
  idProduct          0x0320
  bcdDevice            3.00
  iManufacturer           1 OEM
  iProduct                2 RFID Device (COM)
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              250mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               2
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
Device Status:     0x0000
  (Bus Powered)
Signed-off-by: NMaksim Salau <msalau@iotecha.com>
Acked-by: NOliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      765fb2f1
    • H
      USB: devio: Revert "USB: devio: Don't corrupt user memory" · 845d584f
      由 Hans de Goede 提交于 
      Taking the uurb->buffer_length userspace passes in as a maximum for the
actual urbs transfer_buffer_length causes 2 serious issues:

1) It breaks isochronous support for all userspace apps using libusb,
   as existing libusb versions pass in 0 for uurb->buffer_length,
   relying on the kernel using the lenghts of the usbdevfs_iso_packet_desc
   descriptors passed in added together as buffer length.

   This for example causes redirection of USB audio and Webcam's into
   virtual machines using qemu-kvm to no longer work. This is a userspace
   ABI break and as such must be reverted.

   Note that the original commit does not protect other users / the
   kernels memory, it only stops the userspace process making the call
   from shooting itself in the foot.

2) It may cause the kernel to program host controllers to DMA over random
   memory. Just as the devio code used to only look at the iso_packet_desc
   lenghts, the host drivers do the same, relying on the submitter of the
   urbs to make sure the entire buffer is large enough and not checking
   transfer_buffer_length.

   But the "USB: devio: Don't corrupt user memory" commit now takes the
   userspace provided uurb->buffer_length for the buffer-size while copying
   over the user-provided iso_packet_desc lengths 1:1, allowing the user
   to specify a small buffer size while programming the host controller to
   dma a lot more data.

   (Atleast the ohci, uhci, xhci and fhci drivers do not check
    transfer_buffer_length for isoc transfers.)

This reverts commit fa1ed74e ("USB: devio: Don't corrupt user memory")
fixing both these issues.

Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      845d584f
    • M
      usb: xhci: Handle error condition in xhci_stop_device() · b3207c65
      由 Mayank Rana 提交于 
      xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391 ("xhci: rework command timeout and cancellation,")
Cc: <stable@vger.kernel.org>
Signed-off-by: NMayank Rana <mrana@codeaurora.org>
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3207c65
    • L
      usb: xhci: Reset halted endpoint if trb is noop · 810a624b
      由 Lu Baolu 提交于 
      When a URB is cancled, xhci driver turns the untransferred trbs
into no-ops.  If an endpoint stalls on a no-op trb that belongs
to the cancelled URB, the event handler won't reset the endpoint.
Hence, it will stay halted.

Link: http://marc.info/?l=linux-usb&m=149582598330127&w=2

Cc: <stable@vger.kernel.org>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      810a624b
    • J
      xhci: Cleanup current_cmd in xhci_cleanup_command_queue() · d1aad52c
      由 Jeffy Chen 提交于 
      KASAN reported use-after-free bug when xhci host controller died:
[  176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224
[  176.960846] Write of size 4 at addr ffffffc0cbb01608 by task kworker/3:3/1680
...
[  177.180644] Freed by task 0:
[  177.183882]  kasan_slab_free+0x90/0x15c
[  177.188194]  kfree+0x114/0x28c
[  177.191630]  xhci_cleanup_command_queue+0xc8/0xf8
[  177.196916]  xhci_hc_died+0x84/0x358

Problem here is that when the cmd_timer fired, it would try to access
current_cmd while the command queue is already freed by xhci_hc_died().

Cleanup current_cmd in xhci_cleanup_command_queue() to avoid that.

Fixes: d9f11ba9 ("xhci: Rework how we handle unresponsive or hoptlug removed hosts")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1aad52c
    • M
      xhci: Identify USB 3.1 capable hosts by their port protocol capability · ea7d0d69
      由 Mathias Nyman 提交于 
      Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea7d0d69
  5. 16 10月, 2017 1 次提交
  7. 11 10月, 2017 7 次提交
    • A
      usb: usbtest: fix NULL pointer dereference · 7c80f9e4
      由 Alan Stern 提交于 
      If the usbtest driver encounters a device with an IN bulk endpoint but
no OUT bulk endpoint, it will try to dereference a NULL pointer
(out->desc.bEndpointAddress).  The problem can be solved by adding a
missing test.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAndrey Konovalov <andreyknvl@google.com>
Tested-by: NAndrey Konovalov <andreyknvl@google.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      7c80f9e4
    • A
      usb: gadget: configfs: Fix memory leak of interface directory data · ff74745e
      由 Andrew Gabbasov 提交于 
      Kmemleak checking configuration reports a memory leak in
usb_os_desc_prepare_interf_dir function when rndis function
instance is freed and then allocated again. For example, this
happens with FunctionFS driver with RNDIS function enabled
when "ffs-test" test application is run several times in a row.

The data for intermediate "os_desc" group for interface directories
is allocated as a single VLA chunk and (after a change of default
groups handling) is not ever freed and actually not stored anywhere
besides inside a list of default groups of a parent group.

The fix is to make usb_os_desc_prepare_interf_dir function return
a pointer to allocated data (as a pointer to the first VLA item)
instead of (an unused) integer and to make the caller component
(currently the only one is RNDIS function) responsible for storing
the pointer and freeing the memory when appropriate.

Fixes: 1ae1602d ("configfs: switch ->default groups to a linked list")
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      ff74745e
    • A
      usb: gadget: composite: Fix use-after-free in usb_composite_overwrite_options · aec17e1e
      由 Andrew Gabbasov 提交于 
      KASAN enabled configuration reports an error

    BUG: KASAN: use-after-free in usb_composite_overwrite_options+...
                [libcomposite] at addr ...
    Read of size 1 by task ...

when some driver is un-bound and then bound again.
For example, this happens with FunctionFS driver when "ffs-test"
test application is run several times in a row.

If the driver has empty manufacturer ID string in initial static data,
it is then replaced with generated string. After driver unbinding
the generated string is freed, but the driver data still keep that
pointer. And if the driver is then bound again, that pointer
is re-used for string emptiness check.

The fix is to clean up the driver string data upon its unbinding
to drop the pointer to freed memory.

Fixes: cc2683c3 ("usb: gadget: Provide a default implementation of default manufacturer string")
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      aec17e1e
    • D
      usb: misc: usbtest: Fix overflow in usbtest_do_ioctl() · cb84f568
      由 Dan Carpenter 提交于 
      There used to be a test against "if (param->sglen > MAX_SGLEN)" but it
was removed during a refactor.  It leads to an integer overflow and a
stack overflow in test_queue() if we try to create a too large urbs[]
array on the stack.

There is a second integer overflow in test_queue() as well if
"param->iterations" is too high.  I don't immediately see that it's
harmful but I've added a check to prevent it and silence the static
checker warning.

Fixes: 18fc4ebd ("usb: misc: usbtest: Remove timeval usage")
Acked-by: NDeepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      cb84f568
    • K
      usb: renesas_usbhs: Fix DMAC sequence for receiving zero-length packet · 29c7f3e6
      由 Kazuya Mizuguchi 提交于 
      The DREQE bit of the DnFIFOSEL should be set to 1 after the DE bit of
USB-DMAC on R-Car SoCs is set to 1 after the USB-DMAC received a
zero-length packet. Otherwise, a transfer completion interruption
of USB-DMAC doesn't happen. Even if the driver changes the sequence,
normal operations (transmit/receive without zero-length packet) will
not cause any side-effects. So, this patch fixes the sequence anyway.
Signed-off-by: NKazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[shimoda: revise the commit log]
Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      29c7f3e6
    • A
      USB: dummy-hcd: Fix deadlock caused by disconnect detection · ab219221
      由 Alan Stern 提交于 
      The dummy-hcd driver calls the gadget driver's disconnect callback
under the wrong conditions.  It should invoke the callback when Vbus
power is turned off, but instead it does so when the D+ pullup is
turned off.

This can cause a deadlock in the composite core when a gadget driver
is unregistered:

[   88.361471] ============================================
[   88.362014] WARNING: possible recursive locking detected
[   88.362580] 4.14.0-rc2+ #9 Not tainted
[   88.363010] --------------------------------------------
[   88.363561] v4l_id/526 is trying to acquire lock:
[   88.364062]  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547e03>] composite_disconnect+0x43/0x100 [libcomposite]
[   88.365051]
[   88.365051] but task is already holding lock:
[   88.365826]  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.366858]
[   88.366858] other info that might help us debug this:
[   88.368301]  Possible unsafe locking scenario:
[   88.368301]
[   88.369304]        CPU0
[   88.369701]        ----
[   88.370101]   lock(&(&cdev->lock)->rlock);
[   88.370623]   lock(&(&cdev->lock)->rlock);
[   88.371145]
[   88.371145]  *** DEADLOCK ***
[   88.371145]
[   88.372211]  May be due to missing lock nesting notation
[   88.372211]
[   88.373191] 2 locks held by v4l_id/526:
[   88.373715]  #0:  (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.374814]  #1:  (&(&dum_hcd->dum->lock)->rlock){....}, at: [<ffffffffa05bd48d>] dummy_pullup+0x7d/0xf0 [dummy_hcd]
[   88.376289]
[   88.376289] stack backtrace:
[   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
[   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[   88.379504] Call Trace:
[   88.380019]  dump_stack+0x86/0xc7
[   88.380605]  __lock_acquire+0x841/0x1120
[   88.381252]  lock_acquire+0xd5/0x1c0
[   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
[   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
[   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
[   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
[   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
[   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
[   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
[   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]

This patch changes the code to test the port-power status bit rather
than the port-connect status bit when deciding whether to isue the
callback.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDavid Tulloh <david@tulloh.id.au>
CC: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      ab219221
    • J
      usb: phy: tegra: Fix phy suspend for UDC · 203f44c4
      由 Jon Hunter 提交于 
      Commit dfebb5f4 ("usb: chipidea: Add support for Tegra20/30/114/124")
added UDC support for Tegra but with UDC support enabled, is was found
that Tegra30, Tegra114 and Tegra124 would hang on entry to suspend.

The hang occurred during the suspend of the USB PHY when the Tegra PHY
driver attempted to disable the PHY clock. The problem is that before
the Tegra PHY driver is suspended, the chipidea driver already disabled
the PHY clock and when the Tegra PHY driver suspended, it could not read
DEVLC register and caused the device to hang.

The Tegra USB PHY driver is used by both the Tegra EHCI driver and now
the chipidea UDC driver and so simply removing the disabling of the PHY
clock from the USB PHY driver would not work for the Tegra EHCI driver.
Fortunately, the status of the USB PHY clock can be read from the
USB_SUSP_CTRL register and therefore, to workaround this issue, simply
poll the register prior to disabling the clock in USB PHY driver to see
if clock gating has already been initiated. Please note that it can take
a few uS for the clock to disable and so simply reading this status
register once on entry is not sufficient.

Similarly when turning on the PHY clock, it is possible that the clock
is already enabled or in the process of being enabled, and so check for
this when enabling the PHY.

Please note that no issues are seen with Tegra20 because it has a slightly
different PHY to Tegra30/114/124.

Fixes: dfebb5f4 ("usb: chipidea: Add support for Tegra20/30/114/124")
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Tested-by: NDmitry Osipenko <digetx@gmail.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      203f44c4
  9. 09 10月, 2017 2 次提交
  11. 03 10月, 2017 1 次提交
  13. 28 9月, 2017 11 次提交
  15. 25 9月, 2017 2 次提交