mbox series

[v14,0/9] Add multiport support for DWC3 controllers

Message ID 20240206051825.1038685-1-quic_kriskura@quicinc.com (mailing list archive)
Headers show
Series Add multiport support for DWC3 controllers | expand

Message

Krishna Kurapati Feb. 6, 2024, 5:18 a.m. UTC
Currently the DWC3 driver supports only single port controller which
requires at most two PHYs ie HS and SS PHYs. There are SoCs that has
DWC3 controller with multiple ports that can operate in host mode.
Some of the port supports both SS+HS and other port supports only HS
mode.

This change primarily refactors the Phy logic in core driver to allow
multiport support with Generic Phy's.

Changes have been tested on  QCOM SoC SA8295P which has 4 ports (2
are HS+SS capable and 2 are HS only capable).

Changes in v14:
Moved wrapper binding update to 5th patch in the series as it deals
with only wakeup and not enumeration. The first part of the series
deals with enumeration and the next part deals with wakeup.
Updated commit text for wrapper driver patches.
Added error checks in get_port_index and setup_irq call which were
missing in v13.
Added SOB and CDB tags appropriately for the patches.
Rebased code on top of latest usb next.
DT changes have been removed and will be sent as a seperate series.

Changes in v13:
This series is a subset of patches in v11 as the first 3 patches in v11
have been mereged into usb-next.
Moved dr_mode property from platform specific files to common sc8280xp DT.
Fixed function call wrapping, added comments and replaced #defines with
enum in dwc3-qcom for identifying IRQ index appropriately.
Fixed nitpicks pointed out in v11 for suspend-resume handling.
Added reported-by tag for phy refactoring patch as a compile error was
found by kernel test bot [1].
Removed reviewed-by tag of maintainer for phy refactoring patch as a minor
change of increasing phy-names array size by 2-bytes was done to fix
compilation issue mentioned in [1].

Changes in v12:
Pushed as a subset of acked but no-yet-merged patches of v11 with intent
of making rebase of other patches easy. Active reviewers from community
suggested that it would be better to push the whole series in one go as it
would give good clarity and context for all the patches in the series.
So pushed v13 for the same addressing comments received in v11.

Changes in v11:
Implemented port_count calculation by reading interrupt-names from DT.
Refactored IRQ handling in dwc3-qcom.
Moving of macros to xhci-ext-caps.h made as a separate patch.
Names of interrupts to be displayed on /proc/interrupts set to the ones
present in DT.

Changes in v10:
Refactored phy init/exit/power-on/off functions in dwc3 core
Refactored dwc3-qcom irq registration and handling
Implemented wakeup for multiport irq's
Moved few macros from xhci.h to xhci-ext-caps.h
Fixed nits pointed out in v9
Fixed Co-developed by and SOB tags in patches 5 and 11

Changes in v9:
Added IRQ support for DP/DM/SS MP Irq's of SC8280
Refactored code to read port count by accessing xhci registers

Changes in v8:
Reorganised code in patch-5
Fixed nitpicks in code according to comments received on v7
Fixed indentation in DT patches
Added drive strength for pinctrl nodes in SA8295 DT

Changes in v7:
Added power event irq's for Multiport controller.
Udpated commit text for patch-9 (adding DT changes for enabling first
port of multiport controller on sa8540-ride).
Fixed check-patch warnings for driver code.
Fixed DT binding errors for changes in snps,dwc3.yaml
Reabsed code on top of usb-next

Changes in v6:
Updated comments in code after.
Updated variables names appropriately as per review comments.
Updated commit text in patch-2 and added additional info as per review
comments.
The patch header in v5 doesn't have "PATHCH v5" notation present. Corrected
it in this version.

Changes in v5:
Added DT support for first port of Teritiary USB controller on SA8540-Ride
Added support for reading port info from XHCI Extended Params registers.

Changes in RFC v4:
Added DT support for SA8295p.

Changes in RFC v3:
Incase any PHY init fails, then clear/exit the PHYs that
are already initialized.

Changes in RFC v2:
Changed dwc3_count_phys to return the number of PHY Phandles in the node.
This will be used now in dwc3_extract_num_phys to increment num_usb2_phy 
and num_usb3_phy.
Added new parameter "ss_idx" in dwc3_core_get_phy_ny_node and changed its
structure such that the first half is for HS-PHY and second half is for
SS-PHY.
In dwc3_core_get_phy, for multiport controller, only if SS-PHY phandle is
present, pass proper SS_IDX else pass -1.

Tested enumeration and wakeup on all ports:

/ # lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 018: ID 0781:5567
Bus 001 Device 020: ID 03f0:134a
Bus 002 Device 002: ID 18d1:4ee1
Bus 002 Device 001: ID 1d6b:0003
/ #
/ # dmesg | grep ports
[    0.224450] hub 1-0:1.0: 4 ports detected
[    0.230479] hub 2-0:1.0: 2 ports detecte/ #
/ #
/ # cat /proc/interrupts  |grep phy
158:          1          0          0          0          0          0          0          0       PDC 127 Edge      dp_hs_phy_1
159:          2          0          0          0          0          0          0          0       PDC 126 Edge      dm_hs_phy_1
160:          6          0          0          0          0          0          0          0       PDC 129 Edge      dp_hs_phy_2
161:          3          0          0          0          0          0          0          0       PDC 128 Edge      dm_hs_phy_2
162:          1          0          0          0          0          0          0          0       PDC 131 Edge      dp_hs_phy_3
163:          2          0          0          0          0          0          0          0       PDC 130 Edge      dm_hs_phy_3
164:          2          0          0          0          0          0          0          0       PDC 133 Edge      dp_hs_phy_4
165:          3          0          0          0          0          0          0          0       PDC 132 Edge      dm_hs_phy_4
166:          0          0          0          0          0          0          0          0       PDC  16 Level     ss_phy_1
167:          0          0          0          0          0          0          0          0       PDC  17 Level     ss_phy_2

Links to previous versions:
Link to v13: https://lore.kernel.org/all/20231007154806.605-1-quic_kriskura@quicinc.com/
Link to v12: https://lore.kernel.org/all/20231004165922.25642-1-quic_kriskura@quicinc.com/
Link to v11: https://lore.kernel.org/all/20230828133033.11988-1-quic_kriskura@quicinc.com/
Link to v10: https://lore.kernel.org/all/20230727223307.8096-1-quic_kriskura@quicinc.com/
Link to v9: https://lore.kernel.org/all/20230621043628.21485-1-quic_kriskura@quicinc.com/
Link to v8: https://lore.kernel.org/all/20230514054917.21318-1-quic_kriskura@quicinc.com/
Link to v7: https://lore.kernel.org/all/20230501143445.3851-1-quic_kriskura@quicinc.com/
Link to v6: https://lore.kernel.org/all/20230405125759.4201-1-quic_kriskura@quicinc.com/
Link to v5: https://lore.kernel.org/all/20230310163420.7582-1-quic_kriskura@quicinc.com/
Link to RFC v4: https://lore.kernel.org/all/20230115114146.12628-1-quic_kriskura@quicinc.com/
Link to RFC v3: https://lore.kernel.org/all/1654709787-23686-1-git-send-email-quic_harshq@quicinc.com/#r
Link to RFC v2: https://lore.kernel.org/all/1653560029-6937-1-git-send-email-quic_harshq@quicinc.com/#r

Harsh Agarwal (1):
  usb: dwc3: core: Refactor PHY logic to support Multiport Controller

Krishna Kurapati (8):
  dt-bindings: usb: Add bindings for multiport properties on DWC3
    controller
  usb: dwc3: core: Access XHCI address space temporarily to read port
    info
  usb: dwc3: core: Skip setting event buffers for host only controllers
  dt-bindings: usb: qcom,dwc3: Add bindings for SC8280 Multiport
  usb: dwc3: qcom: Add helper function to request wakeup interrupts
  usb: dwc3: qcom: Refactor IRQ handling in glue driver
  usb: dwc3: qcom: Enable wakeup for applicable ports of multiport
  usb: dwc3: qcom: Add multiport suspend/resume support for wrapper

 .../devicetree/bindings/usb/qcom,dwc3.yaml    |  33 ++
 .../devicetree/bindings/usb/snps,dwc3.yaml    |  13 +-
 drivers/usb/dwc3/core.c                       | 326 +++++++++++++----
 drivers/usb/dwc3/core.h                       |  19 +-
 drivers/usb/dwc3/drd.c                        |  15 +-
 drivers/usb/dwc3/dwc3-qcom.c                  | 329 ++++++++++++------
 6 files changed, 534 insertions(+), 201 deletions(-)

Comments

Dmitry Baryshkov Feb. 6, 2024, 8 a.m. UTC | #1
Hi Krishna,

On Tue, 6 Feb 2024 at 07:18, Krishna Kurapati <quic_kriskura@quicinc.com> wrote:
>
> Currently the DWC3 driver supports only single port controller which
> requires at most two PHYs ie HS and SS PHYs. There are SoCs that has
> DWC3 controller with multiple ports that can operate in host mode.
> Some of the port supports both SS+HS and other port supports only HS
> mode.
>
> This change primarily refactors the Phy logic in core driver to allow
> multiport support with Generic Phy's.
>
> Changes have been tested on  QCOM SoC SA8295P which has 4 ports (2
> are HS+SS capable and 2 are HS only capable).

Thank you for your patches! Have you tested how this patchset
interacts with the USB role-switching?

I'm asking because it might be easier to define DT nodes for each of
USB ports, which can carry the PHY properties (and also other DT
properties if that's required, e.g. the ports / endpoints and
usb-role-switch) rather than pushing all USB PHY links to the root DT
node.

>
> Changes in v14:
> Moved wrapper binding update to 5th patch in the series as it deals
> with only wakeup and not enumeration. The first part of the series
> deals with enumeration and the next part deals with wakeup.
> Updated commit text for wrapper driver patches.
> Added error checks in get_port_index and setup_irq call which were
> missing in v13.
> Added SOB and CDB tags appropriately for the patches.
> Rebased code on top of latest usb next.
> DT changes have been removed and will be sent as a seperate series.
>
> Changes in v13:
> This series is a subset of patches in v11 as the first 3 patches in v11
> have been mereged into usb-next.
> Moved dr_mode property from platform specific files to common sc8280xp DT.
> Fixed function call wrapping, added comments and replaced #defines with
> enum in dwc3-qcom for identifying IRQ index appropriately.
> Fixed nitpicks pointed out in v11 for suspend-resume handling.
> Added reported-by tag for phy refactoring patch as a compile error was
> found by kernel test bot [1].
> Removed reviewed-by tag of maintainer for phy refactoring patch as a minor
> change of increasing phy-names array size by 2-bytes was done to fix
> compilation issue mentioned in [1].
>
> Changes in v12:
> Pushed as a subset of acked but no-yet-merged patches of v11 with intent
> of making rebase of other patches easy. Active reviewers from community
> suggested that it would be better to push the whole series in one go as it
> would give good clarity and context for all the patches in the series.
> So pushed v13 for the same addressing comments received in v11.
>
> Changes in v11:
> Implemented port_count calculation by reading interrupt-names from DT.
> Refactored IRQ handling in dwc3-qcom.
> Moving of macros to xhci-ext-caps.h made as a separate patch.
> Names of interrupts to be displayed on /proc/interrupts set to the ones
> present in DT.
>
> Changes in v10:
> Refactored phy init/exit/power-on/off functions in dwc3 core
> Refactored dwc3-qcom irq registration and handling
> Implemented wakeup for multiport irq's
> Moved few macros from xhci.h to xhci-ext-caps.h
> Fixed nits pointed out in v9
> Fixed Co-developed by and SOB tags in patches 5 and 11
>
> Changes in v9:
> Added IRQ support for DP/DM/SS MP Irq's of SC8280
> Refactored code to read port count by accessing xhci registers
>
> Changes in v8:
> Reorganised code in patch-5
> Fixed nitpicks in code according to comments received on v7
> Fixed indentation in DT patches
> Added drive strength for pinctrl nodes in SA8295 DT
>
> Changes in v7:
> Added power event irq's for Multiport controller.
> Udpated commit text for patch-9 (adding DT changes for enabling first
> port of multiport controller on sa8540-ride).
> Fixed check-patch warnings for driver code.
> Fixed DT binding errors for changes in snps,dwc3.yaml
> Reabsed code on top of usb-next
>
> Changes in v6:
> Updated comments in code after.
> Updated variables names appropriately as per review comments.
> Updated commit text in patch-2 and added additional info as per review
> comments.
> The patch header in v5 doesn't have "PATHCH v5" notation present. Corrected
> it in this version.
>
> Changes in v5:
> Added DT support for first port of Teritiary USB controller on SA8540-Ride
> Added support for reading port info from XHCI Extended Params registers.
>
> Changes in RFC v4:
> Added DT support for SA8295p.
>
> Changes in RFC v3:
> Incase any PHY init fails, then clear/exit the PHYs that
> are already initialized.
>
> Changes in RFC v2:
> Changed dwc3_count_phys to return the number of PHY Phandles in the node.
> This will be used now in dwc3_extract_num_phys to increment num_usb2_phy
> and num_usb3_phy.
> Added new parameter "ss_idx" in dwc3_core_get_phy_ny_node and changed its
> structure such that the first half is for HS-PHY and second half is for
> SS-PHY.
> In dwc3_core_get_phy, for multiport controller, only if SS-PHY phandle is
> present, pass proper SS_IDX else pass -1.
>
> Tested enumeration and wakeup on all ports:
>
> / # lsusb
> Bus 001 Device 001: ID 1d6b:0002
> Bus 001 Device 018: ID 0781:5567
> Bus 001 Device 020: ID 03f0:134a
> Bus 002 Device 002: ID 18d1:4ee1
> Bus 002 Device 001: ID 1d6b:0003
> / #
> / # dmesg | grep ports
> [    0.224450] hub 1-0:1.0: 4 ports detected
> [    0.230479] hub 2-0:1.0: 2 ports detecte/ #
> / #
> / # cat /proc/interrupts  |grep phy
> 158:          1          0          0          0          0          0          0          0       PDC 127 Edge      dp_hs_phy_1
> 159:          2          0          0          0          0          0          0          0       PDC 126 Edge      dm_hs_phy_1
> 160:          6          0          0          0          0          0          0          0       PDC 129 Edge      dp_hs_phy_2
> 161:          3          0          0          0          0          0          0          0       PDC 128 Edge      dm_hs_phy_2
> 162:          1          0          0          0          0          0          0          0       PDC 131 Edge      dp_hs_phy_3
> 163:          2          0          0          0          0          0          0          0       PDC 130 Edge      dm_hs_phy_3
> 164:          2          0          0          0          0          0          0          0       PDC 133 Edge      dp_hs_phy_4
> 165:          3          0          0          0          0          0          0          0       PDC 132 Edge      dm_hs_phy_4
> 166:          0          0          0          0          0          0          0          0       PDC  16 Level     ss_phy_1
> 167:          0          0          0          0          0          0          0          0       PDC  17 Level     ss_phy_2
>
> Links to previous versions:
> Link to v13: https://lore.kernel.org/all/20231007154806.605-1-quic_kriskura@quicinc.com/
> Link to v12: https://lore.kernel.org/all/20231004165922.25642-1-quic_kriskura@quicinc.com/
> Link to v11: https://lore.kernel.org/all/20230828133033.11988-1-quic_kriskura@quicinc.com/
> Link to v10: https://lore.kernel.org/all/20230727223307.8096-1-quic_kriskura@quicinc.com/
> Link to v9: https://lore.kernel.org/all/20230621043628.21485-1-quic_kriskura@quicinc.com/
> Link to v8: https://lore.kernel.org/all/20230514054917.21318-1-quic_kriskura@quicinc.com/
> Link to v7: https://lore.kernel.org/all/20230501143445.3851-1-quic_kriskura@quicinc.com/
> Link to v6: https://lore.kernel.org/all/20230405125759.4201-1-quic_kriskura@quicinc.com/
> Link to v5: https://lore.kernel.org/all/20230310163420.7582-1-quic_kriskura@quicinc.com/
> Link to RFC v4: https://lore.kernel.org/all/20230115114146.12628-1-quic_kriskura@quicinc.com/
> Link to RFC v3: https://lore.kernel.org/all/1654709787-23686-1-git-send-email-quic_harshq@quicinc.com/#r
> Link to RFC v2: https://lore.kernel.org/all/1653560029-6937-1-git-send-email-quic_harshq@quicinc.com/#r
>
> Harsh Agarwal (1):
>   usb: dwc3: core: Refactor PHY logic to support Multiport Controller
>
> Krishna Kurapati (8):
>   dt-bindings: usb: Add bindings for multiport properties on DWC3
>     controller
>   usb: dwc3: core: Access XHCI address space temporarily to read port
>     info
>   usb: dwc3: core: Skip setting event buffers for host only controllers
>   dt-bindings: usb: qcom,dwc3: Add bindings for SC8280 Multiport
>   usb: dwc3: qcom: Add helper function to request wakeup interrupts
>   usb: dwc3: qcom: Refactor IRQ handling in glue driver
>   usb: dwc3: qcom: Enable wakeup for applicable ports of multiport
>   usb: dwc3: qcom: Add multiport suspend/resume support for wrapper
>
>  .../devicetree/bindings/usb/qcom,dwc3.yaml    |  33 ++
>  .../devicetree/bindings/usb/snps,dwc3.yaml    |  13 +-
>  drivers/usb/dwc3/core.c                       | 326 +++++++++++++----
>  drivers/usb/dwc3/core.h                       |  19 +-
>  drivers/usb/dwc3/drd.c                        |  15 +-
>  drivers/usb/dwc3/dwc3-qcom.c                  | 329 ++++++++++++------
>  6 files changed, 534 insertions(+), 201 deletions(-)
>
> --
> 2.34.1
>
>
Krishna Kurapati Feb. 6, 2024, 8:15 a.m. UTC | #2
On 2/6/2024 1:30 PM, Dmitry Baryshkov wrote:
> Hi Krishna,
> 
> On Tue, 6 Feb 2024 at 07:18, Krishna Kurapati <quic_kriskura@quicinc.com> wrote:
>>
>> Currently the DWC3 driver supports only single port controller which
>> requires at most two PHYs ie HS and SS PHYs. There are SoCs that has
>> DWC3 controller with multiple ports that can operate in host mode.
>> Some of the port supports both SS+HS and other port supports only HS
>> mode.
>>
>> This change primarily refactors the Phy logic in core driver to allow
>> multiport support with Generic Phy's.
>>
>> Changes have been tested on  QCOM SoC SA8295P which has 4 ports (2
>> are HS+SS capable and 2 are HS only capable).
> 
> Thank you for your patches! Have you tested how this patchset
> interacts with the USB role-switching?
> 
> I'm asking because it might be easier to define DT nodes for each of
> USB ports, which can carry the PHY properties (and also other DT
> properties if that's required, e.g. the ports / endpoints and
> usb-role-switch) rather than pushing all USB PHY links to the root DT
> node.
> 

Hi Dmitry,

  Role switching doesn't work for Multiport controller as it is host 
only capable. I don't think it will cause any issues for OTG capable 
controllers because they only have one HS and SS phy present. So there 
is no possibility or requirement for having endpoints per port in this case.

Regards,
Krishna,
Dmitry Baryshkov Feb. 6, 2024, 8:43 a.m. UTC | #3
On Tue, 6 Feb 2024 at 10:15, Krishna Kurapati PSSNV
<quic_kriskura@quicinc.com> wrote:
>
>
>
> On 2/6/2024 1:30 PM, Dmitry Baryshkov wrote:
> > Hi Krishna,
> >
> > On Tue, 6 Feb 2024 at 07:18, Krishna Kurapati <quic_kriskura@quicinc.com> wrote:
> >>
> >> Currently the DWC3 driver supports only single port controller which
> >> requires at most two PHYs ie HS and SS PHYs. There are SoCs that has
> >> DWC3 controller with multiple ports that can operate in host mode.
> >> Some of the port supports both SS+HS and other port supports only HS
> >> mode.
> >>
> >> This change primarily refactors the Phy logic in core driver to allow
> >> multiport support with Generic Phy's.
> >>
> >> Changes have been tested on  QCOM SoC SA8295P which has 4 ports (2
> >> are HS+SS capable and 2 are HS only capable).
> >
> > Thank you for your patches! Have you tested how this patchset
> > interacts with the USB role-switching?
> >
> > I'm asking because it might be easier to define DT nodes for each of
> > USB ports, which can carry the PHY properties (and also other DT
> > properties if that's required, e.g. the ports / endpoints and
> > usb-role-switch) rather than pushing all USB PHY links to the root DT
> > node.
> >
>
> Hi Dmitry,
>
>   Role switching doesn't work for Multiport controller as it is host
> only capable. I don't think it will cause any issues for OTG capable
> controllers because they only have one HS and SS phy present. So there
> is no possibility or requirement for having endpoints per port in this case.

Is it going to remain host-only in future?



--
With best wishes
Dmitry
Krishna Kurapati Feb. 6, 2024, 8:45 a.m. UTC | #4
On 2/6/2024 2:13 PM, Dmitry Baryshkov wrote:
> On Tue, 6 Feb 2024 at 10:15, Krishna Kurapati PSSNV
> <quic_kriskura@quicinc.com> wrote:
>>
>>
>>
>> On 2/6/2024 1:30 PM, Dmitry Baryshkov wrote:
>>> Hi Krishna,
>>>
>>> On Tue, 6 Feb 2024 at 07:18, Krishna Kurapati <quic_kriskura@quicinc.com> wrote:
>>>>
>>>> Currently the DWC3 driver supports only single port controller which
>>>> requires at most two PHYs ie HS and SS PHYs. There are SoCs that has
>>>> DWC3 controller with multiple ports that can operate in host mode.
>>>> Some of the port supports both SS+HS and other port supports only HS
>>>> mode.
>>>>
>>>> This change primarily refactors the Phy logic in core driver to allow
>>>> multiport support with Generic Phy's.
>>>>
>>>> Changes have been tested on  QCOM SoC SA8295P which has 4 ports (2
>>>> are HS+SS capable and 2 are HS only capable).
>>>
>>> Thank you for your patches! Have you tested how this patchset
>>> interacts with the USB role-switching?
>>>
>>> I'm asking because it might be easier to define DT nodes for each of
>>> USB ports, which can carry the PHY properties (and also other DT
>>> properties if that's required, e.g. the ports / endpoints and
>>> usb-role-switch) rather than pushing all USB PHY links to the root DT
>>> node.
>>>
>>
>> Hi Dmitry,
>>
>>    Role switching doesn't work for Multiport controller as it is host
>> only capable. I don't think it will cause any issues for OTG capable
>> controllers because they only have one HS and SS phy present. So there
>> is no possibility or requirement for having endpoints per port in this case.
> 
> Is it going to remain host-only in future?
> 
> 
Yes. I believe these are designed that way. I don't know of any 
controllers that have multiple ports and device mode works. Device mode 
can work only on one port AFAIK.

Regards,
Krishna,
Dmitry Baryshkov Feb. 6, 2024, 8:47 a.m. UTC | #5
On Tue, 6 Feb 2024 at 10:45, Krishna Kurapati PSSNV
<quic_kriskura@quicinc.com> wrote:
>
>
>
> On 2/6/2024 2:13 PM, Dmitry Baryshkov wrote:
> > On Tue, 6 Feb 2024 at 10:15, Krishna Kurapati PSSNV
> > <quic_kriskura@quicinc.com> wrote:
> >>
> >>
> >>
> >> On 2/6/2024 1:30 PM, Dmitry Baryshkov wrote:
> >>> Hi Krishna,
> >>>
> >>> On Tue, 6 Feb 2024 at 07:18, Krishna Kurapati <quic_kriskura@quicinc.com> wrote:
> >>>>
> >>>> Currently the DWC3 driver supports only single port controller which
> >>>> requires at most two PHYs ie HS and SS PHYs. There are SoCs that has
> >>>> DWC3 controller with multiple ports that can operate in host mode.
> >>>> Some of the port supports both SS+HS and other port supports only HS
> >>>> mode.
> >>>>
> >>>> This change primarily refactors the Phy logic in core driver to allow
> >>>> multiport support with Generic Phy's.
> >>>>
> >>>> Changes have been tested on  QCOM SoC SA8295P which has 4 ports (2
> >>>> are HS+SS capable and 2 are HS only capable).
> >>>
> >>> Thank you for your patches! Have you tested how this patchset
> >>> interacts with the USB role-switching?
> >>>
> >>> I'm asking because it might be easier to define DT nodes for each of
> >>> USB ports, which can carry the PHY properties (and also other DT
> >>> properties if that's required, e.g. the ports / endpoints and
> >>> usb-role-switch) rather than pushing all USB PHY links to the root DT
> >>> node.
> >>>
> >>
> >> Hi Dmitry,
> >>
> >>    Role switching doesn't work for Multiport controller as it is host
> >> only capable. I don't think it will cause any issues for OTG capable
> >> controllers because they only have one HS and SS phy present. So there
> >> is no possibility or requirement for having endpoints per port in this case.
> >
> > Is it going to remain host-only in future?
> >
> >
> Yes. I believe these are designed that way. I don't know of any
> controllers that have multiple ports and device mode works. Device mode
> can work only on one port AFAIK.

Ack, thanks for the explanation.