initialize (multiple) PHYs in xhci-plat

Quoted 95 lines · Jerome Brunet

Quoted 93 lines · Martin Blumenstingl

Hello Greg, Hello Mathias,

Quoted 80 lines · Greg KH

Quoted 79 lines · Martin Blumenstingl

Hello Mathias, Hello Greg,

Quoted 54 lines · Martin Blumenstingl

This series is the outcome of a discussion with Felipe Balbi, see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
ohci-platform.c) do not have a limitation on the number of PHYs -
they
support one PHY per actual host port
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
or three USB2 ports enabled on the internal root-hub. The SoCs
also
provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY
is
disabled and if the device is plugged into another, enabled port)

In my first attempt to get USB supported on the GXL and GXM SoCs I tried
to work-around the problem that I could not pass multiple PHYs to the
dwc3 controller.
This was rejected by Rob Herring (which was definitely the thing to do
in
my opinion), see [2]

This series adds a new "platform-roothub". This can be configured through
devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on
the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the
USB device binding (documented in devicetree/bindings/usb/usb- device.txt)
This avoids and backwards-compatibility problems (which was a concern
regardless of the solution, see [3]) since the binding for the root- hub
was previously not specified (and we're not using the "phys" property of
the controller, which might have served different purposes before, depending on the drivers).

Additionally this integrates the new platform-roothub into xhci- plat.c
which automatically enables it for the dwc3 driver (in host-mode).

Quoted 11 lines

Changes since RFCv3 at [6]:
- moved the DT binding change from patch #3 to patch #1 as suggested by Rob Herring (and slightly adjusted the commit message to
account
for that)
- added Tested-by from Chunfeng Yun (who confirmed that the whole concept and implementation works fine on Mediatek SoCs - many
thanks
again!) to patch #2
- added Rob Herring's ACK to patches 1 and 3
- dropped RFC status (RFCv3 -> PATCH v4)

I just wanted to rebase this to v4.14-rc1 (now that this is out) - however I noticed that v4 still applies to v4.14-rc1 cleanly (the patches are still identical to v4 after rebasing).

we have an ACK from the devicetree maintainers and a "Tested-by" for a Mediatek (= non-Amlogic) SoC.
I already have patches for the Amlogic GXL/GXM platforms queued, those are just waiting on this series.

Quoted 4 lines

Quoted 1 line

what is still missing to get this series into v4.15?

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let us catch up on patch review please...

OK, I understand that.
please let me know once you've caught up with the review backlog - as I said I would like to get this into 4.15 if nothing else comes up during the code-review

Quoted 4 lines

This series works well on the libretech-cc (le potato) For the series:

Tested-by Jerome Brunet <[email protected]>

Hey, I have one of those boards now, was just about to try to get it to work. Is this series necessary for it to run properly on 4.14-rc?

thanks,

greg k-h