On Fri, Nov 4, 2011 at 1:46 PM, Pavan Kondeti <pkondeti@xxxxxxxxxxxxxx> wrote: > On 11/4/2011 10:15 PM, Grant Likely wrote: >> The host controller node names as "usb@<adddr>" as you have here is >> exactly right. The driver doesn't care and will only look at the >> compatible list. OTG controllers can also use "usb@" as the prefix. >> >> Controllers that are only in device mode should probably be called >> something like "usb-gadget@<addr>" or similar, because "usb@" is used >> for host controllers. >> > > In our case OTG, gadget and host controllers are part of a single core > i.e they all share the same register address space. > > If I use usb@addr for OTG controller, then host and OTG device node > names becomes same. Is that okay? Can two devices have the same device > node name in device tree source file? It is not legal for two device nodes to have overlapping 'reg' regions (unless one is a child of the other), so by extension it is not okay for two nodes to have the same 'name@addr'. However, it is perfectly acceptable and encouraged for two nodes at different addresses to start with the same value for 'name@'. This is called the generic names recommended practice, and it can also be found in the ePAPR documentation on node names. If you want to have both host and device drivers bound to a single device for OTG mode, then you should use a wrapper driver in Linux that binds to the single node and instantiates each of the interfaces as a child device. For an example take a look at drivers/usb/host/fsl-mph-dr-of.c. > >> The label names (hsusb*-host, hsusb*-device) are completely irrelevant >> since Linux never sees them. Use whatever you want for the label >> names. >> > Is it a good practice to give label names? I thought, it improves a bit > readability of device tree source file. Yes, label names are important; the kernel just never sees them so I don't care much. g. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
