Hi Stefan,
Thanks for looking into this. There are examples of standalone
"snps,dwc3" nodes, such as rp1_usb0 and rp1_usb1 in
dts/upstream/src/arm64/broadcom/rp1-common.dtsi.
What I am still missing is the binding path from such a node to
dwc3_generic_probe(). Neither dwc3-generic-host nor
dwc3-generic-peripheral has an of_match table. The direct "snps,dwc3"
match is provided by xhci-dwc3, when that driver is enabled, and uses a
separate probe implementation.
The platform binding path I found for the two generic drivers is
dwc3_glue_bind_common(), called by dwc3_glue_bind():
device_bind_driver_to_node(parent, driver, name, node, &dev);
Here, parent is the glue device. This also holds for the flattened-DT
case: the glue and controller devices share an ofnode, but the controller
device is still bound as a child of the glue device.
So my understanding is that merely describing a standalone "snps,dwc3"
node would not make dwc3_generic_probe() run with an unrelated bus device
as its parent. On the current normal in-tree binding paths, the proposed
driver-name test would pass.
Is there another binding path you had in mind?
An explicit check could still serve as a defensive guard. My concern with
strstr() is that it checks a naming convention rather than the parent's
role. If documenting the existing assumption is sufficient, a comment
explaining that dev->parent is the glue device which bound this controller
might help.
I am happy to leave the choice of guard to you and Marek - this is just
to clarify the binding path.
Regards,
Tom
