Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 165
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 6月, 2016 1 次提交
    • T
      usb: xhci-plat: properly handle probe deferral for devm_clk_get() · de95c40d
      由 Thomas Petazzoni 提交于 
      On some platforms, the clocks might be registered by a platform
driver. When this is the case, the clock platform driver may very well
be probed after xhci-plat, in which case the first probe() invocation
of xhci-plat will receive -EPROBE_DEFER as the return value of
devm_clk_get().

The current code handles that as a normal error, and simply assumes
that this means that the system doesn't have a clock for the XHCI
controller, and continues probing without calling
clk_prepare_enable(). Unfortunately, this doesn't work on systems
where the XHCI controller does have a clock, but that clock is
provided by another platform driver. In order to fix this situation,
we handle the -EPROBE_DEFER error condition specially, and abort the
XHCI controller probe(). It will be retried later automatically, the
clock will be available, devm_clk_get() will succeed, and the probe()
will continue with the clock prepared and enabled as expected.

In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
where the clocks are registered by a platform driver.

Cc: <stable@vger.kernel.org>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de95c40d
  3. 27 4月, 2016 4 次提交
  5. 14 4月, 2016 1 次提交
  7. 04 3月, 2016 2 次提交
  9. 04 2月, 2016 1 次提交
  11. 02 12月, 2015 5 次提交
  13. 17 10月, 2015 2 次提交
  15. 31 5月, 2015 3 次提交
  17. 18 3月, 2015 1 次提交
  19. 25 2月, 2015 1 次提交
    • M
      usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks · 1e7e4fb6
      由 Maxime Ripard 提交于 
      The commit 97374792 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.

However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.

Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.

Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e7e4fb6
  21. 22 11月, 2014 1 次提交
  23. 08 11月, 2014 1 次提交
  25. 04 10月, 2014 2 次提交
  27. 10 7月, 2014 4 次提交
  29. 29 5月, 2014 1 次提交
  31. 28 5月, 2014 4 次提交
  33. 05 3月, 2014 1 次提交
  35. 16 2月, 2014 1 次提交
  37. 11 12月, 2013 1 次提交
    • D
      usb: xhci: change enumeration scheme to 'new scheme' by default · 48fc7dbd
      由 Dan Williams 提交于 
      Change the default enumeration scheme for xhci attached non-SuperSpeed
devices from:

   Reset
   SetAddress [xhci address-device BSR = 0]
   GetDescriptor(8)
   GetDescriptor(18)

...to:

   Reset
   [xhci address-device BSR = 1]
   GetDescriptor(64)
   Reset
   SetAddress [xhci address-device BSR = 0]
   GetDescriptor(18)

...as some devices misbehave when encountering a SetAddress command
prior to GetDescriptor.  There are known legacy devices that require
this scheme, but testing has found at least one USB3 device that fails
enumeration when presented with this ordering.  For now, follow the ehci
case and enable 'new scheme' by default for non-SuperSpeed devices.

To support this enumeration scheme on xhci the AddressDevice operation
needs to be performed twice.  The first instance of the command enables
the HC's device and slot context info for the device, but omits sending
the device a SetAddress command (BSR == block set address request).
Then, after GetDescriptor completes, follow up with the full
AddressDevice+SetAddress operation.

As mentioned before, this ordering of events with USB3 devices causes an
extra state transition to be exposed to xhci.  Previously USB3 devices
would transition directly from 'enabled' to 'addressed' and never need
to underrun responses to 'get descriptor'. We do see the 64-byte
descriptor fetch the correct data, but the following 18-byte descriptor
read after the reset gets:

bLength            = 0
bDescriptorType    = 0
bcdUSB             = 0
bDeviceClass       = 0
bDeviceSubClass    = 0
bDeviceProtocol    = 0
bMaxPacketSize0    = 9

instead of:

bLength            = 12
bDescriptorType    = 1
bcdUSB             = 300
bDeviceClass       = 0
bDeviceSubClass    = 0
bDeviceProtocol    = 0
bMaxPacketSize0    = 9

which results in the discovery process looping until falling back to
'old scheme' enumeration.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDavid Moore <david.moore@gmail.com>
Suggested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      48fc7dbd
  39. 09 12月, 2013 1 次提交
  41. 16 8月, 2013 1 次提交
    • S
      xhci-plat: Don't enable legacy PCI interrupts. · 52fb6125
      由 Sarah Sharp 提交于 
      The xHCI platform driver calls into usb_add_hcd to register the irq for
its platform device.  It does not want the xHCI generic driver to
register an interrupt for it at all.  The original code did that by
setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
enable MSI or MSI-X for a PCI host.

Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
the xHCI generic driver will attempt to register a legacy PCI interrupt
for the xHCI platform device in xhci_try_enable_msi().  This will result
in a bogus irq being registered, since the underlying device is a
platform_device, not a pci_device, and thus the pci_device->irq pointer
will be bogus.

Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
distinguish between a PCI device that can't handle MSI or MSI-X, and a
platform device that should not have its interrupts touched at all.
This quirk may be useful in the future, in case other corner cases like
this arise.

This patch should be backported to kernels as old as 3.9, that
contain the commit 00eed9c8 "USB: xhci:
correctly enable interrupts".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: NYu Y Wang <yu.y.wang@intel.com>
Tested-by: NYu Y Wang <yu.y.wang@intel.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Cc: stable@vger.kernel.org
      52fb6125
  43. 14 8月, 2013 1 次提交
    • X
      xhci: fix dma mask setup in xhci.c · c10cf118
      由 Xenia Ragiadakou 提交于 
      The function dma_set_mask() tests internally whether the dma_mask pointer
for the device is initialized and fails if the dma_mask pointer is NULL.
On pci platforms, the device dma_mask pointer is initialized, when pci
devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff.
However, for non-pci platforms, the dma_mask pointer may not be initialized
and in that case dma_set_mask() will fail.

This patch initializes the dma_mask and the coherent_dma_mask to 32bits
in xhci_plat_probe(), before the call to usb_create_hcd() that sets the
"uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates
coherent dma pools for the usb hcd.

Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask.
Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc()
to allocate consistent DMA memory blocks, the coherent DMA address mask
has to be set explicitly.

This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when
the xHC is capable for 64-bit DMA addressing.

If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that
the given bitmask is also supported for consistent DMA mappings.

Other changes introduced in this patch are:

- The return value of dma_set_mask() is checked to ensure that the required
  dma bitmask conforms with the host system's addressing capabilities.

- The dma_mask setup code for the non-primary hcd was removed since both
  primary and non-primary hcd refer to the same generic device whose
  dma_mask and coherent_dma_mask are already set during the setup of
  the primary hcd.

- The code for reading the HCCPARAMS register to find out the addressing
  capabilities of xHC was removed since its value is already cached in
  xhci->hccparams.

- hcd->self.controller was replaced with the dev variable since it is
  already available.
Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c10cf118