Skip to content

ARM: mvebu: Enable XHCI on the Armada 385 AP

Andrew Lunn linux-arm-kernel 4 versions – New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest posting 3/30 of 3 patches 0 repliesNew
  2. v2 posting 2/30 of 3 patches 0 repliesSuperseded
  3. v2 posting 1/30 of 3 patches 0 repliesSuperseded
Earlier versions · 1
VersionPostedPatchesRepliesStatus
v12 patches0 repliesSuperseded

Patches in v2 posting 3/3 No applies recorded yet

None of the 3 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

Cover letter [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
Quoted 33 lines · Maxime Ripard

Hi Andrew,

Quoted 30 lines · Andrew Lunn
Quoted 19 lines · Maxime Ripard

Hi all,

This serie enables the Armada 385 AP XHCI controller.

Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.

Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.

Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.

Quoted 3 lines

The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.

Hi Maxime

I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc.

Quoted 6 lines
Quoted 1 line

What route do you think the other patches will take?

There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree.

Hi Maxime

Humm, maybe i'm wrong, but i think

arch/arm/boot/dts/armada-385-db-ap.dts

only exists in the mvebu tree?

At least, i don't see it here:

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next

Andrew