<p><br>
On Nov 4, 2011 11:08 PM, "Pavan Kondeti" <<a href="mailto:pkondeti@codeaurora.org">pkondeti@codeaurora.org</a>> wrote:<br>
><br>
> Hi<br>
><br>
> On 11/4/2011 11:42 PM, Grant Likely wrote:<br>
> > It is not legal for two device nodes to have overlapping 'reg' regions<br>
> > (unless one is a child of the other), so by extension it is not okay<br>
> > for two nodes to have the same 'name@addr'.  However, it is perfectly<br>
> > acceptable and encouraged for two nodes at different addresses to<br>
> > start with the same value for 'name@'.  This is called the generic<br>
> > names recommended practice, and it can also be found in the ePAPR<br>
> > documentation on node names.<br>
> ><br>
> > If you want to have both host and device drivers bound to a single<br>
> > device for OTG mode, then you should use a wrapper driver in Linux<br>
> > that binds to the single node and instantiates each of the interfaces<br>
> > as a child device.  For an example take a look at<br>
> > drivers/usb/host/fsl-mph-dr-of.c.<br>
><br>
> Currently we have two platform devices one for OTG and one for host,<br>
> corresponding drivers for them. If I would like to keep it this way, the<br>
> device tree becomes something like below<br>
><br>
> hsusb0-otg: usb-otg@0xa6000000 {<br>
>        compatible = "qcom,hsusb-otg";<br>
>        ---<br>
> };<br>
><br>
> hsusb0-device: usb-gadget@0xa6000000 {<br>
>        compatible = "qcom,hsusb-device";<br>
>        ---<br>
> };<br>
><br>
> hsusb0-host: usb@0xa6000000 {<br>
>        compatible = "qcom,hsusb-host", "usb-ehci";<br>
>        ---<br>
> };</p>
<p>No, you don't need three nodes. Only one node for the whole thing since from the hardware perspective it is still a single device. The driver for that node should create the child otg and gadget platform_devices so that you can preserve the existing driver structure.</p>

<p>There does not need to be a device tree node for every struct device in the kernel.</p>
<p>g.</p>
<p>><br>
> Are you okay with above naming convention?<br>
><br>
> --<br>
> Sent by a consultant of the Qualcomm Innovation Center, Inc.<br>
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.<br>
</p>