Re: [PATCH v3 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs

Hi Konrad,

On Wed, Jul 29, 2026 at 12:46:49PM +0200, Konrad Dybcio wrote:
> On 7/29/26 12:27 PM, Wei Deng wrote:
>> Number the existing High-Speed data bus port of the usb_2 DWC3
>> controller as port@0, consistent with the snps,dwc3 binding convention.
>>
>> Also add an empty port@1 endpoint stub (usb_2_m2_ep) for the USB 2.0
>> interface to M.2 peripherals, and an empty UART endpoint stub
>> (uart14_ep) in the uart14 serial controller, so that board DTS files
>> can reference these labels directly without re-entering the port
>> hierarchy.
>>
>> Signed-off-by: Wei Deng <[email protected]>
>> ---
>
> [...]
>
>> -			port {
>> -				usb_2_dwc3_hs: endpoint {
>> +			ports {
>> +				#address-cells = <1>;
>> +				#size-cells = <0>;
>> +
>> +				port@0 {
>> +					reg = <0>;
>> +
>> +					usb_2_dwc3_hs: endpoint {
>> +					};
>> +				};
>> +
>> +				port@1 {
>> +					reg = <1>;
>> +
>> +					usb_2_m2_ep: endpoint {
>> +					};
>
> What? Why?
>
> 1. what's wrong with assigning the existing endpoint to the m2 graph?
> 2. this breaks bindings - port@1 is supposed to represent the superspeed
>    connection
> 3. why would we have two endpoints for the same physical HS connection?
>
> Konrad

Thanks for the review. I tried (1) locally — repointing the existing
usb_2_dwc3_hs endpoint at the M.2 graph and keeping the singular
"port { endpoint { ... } }" structure — and hit a functional failure
I'd like your and Chen-Yu's input on before v4.

Test on Hamoa IoT EVK with the Chen-Yu Tsai V6 pwrseq series applied [1]:

  Option A (v3 as posted: ports { port@0 { usb_2_dwc3_hs }; port@1 {
  usb_2_m2_ep }; }):
      BT USB device enumerates; pwrseq_m2 refcount matches expectation.

  Option (1) (singular port { usb_2_dwc3_hs } with remote-endpoint
  pointing to M.2's port@2):
      BT USB does not enumerate; pwrseq_m2 refcount is 1 less than the
      Option A run.

Root cause, following the V6 series:

  V6 patch 6 (usb: hub: Associate port@ fwnode with USB port device),
  for each USB roothub port, calls

      fwnode_graph_get_port_by_id(fwnode, port1, ...)

  where port1 is the USB port number (starts at 1). usb_2 is HS-only
  (maximum-speed = "high-speed", single usb2-phy), so this is called
  with port1 = 1 and looks up a DT node with reg = <1>.

  V6 patch 12 (pwrseq-pcie-m2: support matching on remote "port"
  node) uses of_graph_get_remote_port(endpoint) to match the USB port
  device's of_node against the M.2 endpoint's remote port.

Under Option (1) the singular "port { }" has no reg, so
port_by_id(1) returns NULL, port_dev->dev.of_node is left NULL, the
pcie-m2 match falls through, pwrseq_get() is never called for the USB
target, port->pwrseq stays NULL, and W_DISABLE2# is never deasserted
from the USB path. That's the missing refcount and the failed
enumeration. Under Option A, port@1's reg = <1> matches port1 = 1,
graph walks all the way to the M.2 slot and pwrseq_get() succeeds.

So on your (2) and (3): I don't disagree that "port@1 = SS" and "one
endpoint per physical HS connection" are what the current
snps,dwc3-common.yaml wants. The v3 shape is what works against the V6
fwnode lookup, not what I think is semantically clean. Choice seems to
be between:

  (a) keep "port@1 = SS" — then USB port 1 on a HS-only DWC3 has
      nowhere to advertise its downstream connector node to the V6
      lookup, and this M.2 wiring is not expressible; or

  (b) renumber snps,dwc3 ports to match USB port numbering (port@1 =
      HS if HS-only or SS if SS-capable, port@2 = HS if SS-capable),
      parallel to Chen-Yu's mediatek,mtk-xhci change in V6 patch 11 [2].

I want to avoid redefining the binding unilaterally, so two questions:

  Konrad: is there a DTS pattern I'm missing that would satisfy the
  current binding and still let fwnode_graph_get_port_by_id(fwnode, 1,
  ...) land on the M.2 connector for USB port 1? If not, would you be
  open to a snps,dwc3-common.yaml renumbering patch along the lines of
  Chen-Yu's mtk-xhci change?

  Chen-Yu: given the parallel with your patch 11, does snps,dwc3 need
  the same treatment on the QCom side, and would you rather see that
  patch go in ahead of your V6 or as a followup?

The 3/3 sort-order comment will be fixed in v4 regardless.

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/

Thanks,

-- 
Best Regards,
Wei Deng