USB support for device tree

Hi

I am working on adding USB device tree support for MSM platform. One of our chip set has 2 hsusb cores. The first core is configured as otg and the other core is configured in host only mode (EHCI compliant). Are the below device node names Okay? Please suggest.

Quoted 6 lines · Pavan Kondeti

Hi

I am working on adding USB device tree support for MSM platform.  One of our chip set has 2 hsusb cores. The first core is configured as otg and the other core is configured in host only mode (EHCI compliant). Are the below device node names Okay? Please suggest.

Why do you need to name the speed of the device and the host?  That doesn't really matter if you plug a low-speed device into that super speed host controller, right?

I'm not familiar with device tree naming conventions, but is this something you do for network devices?  If not, I'd not recommend it for USB controllers either.

Quoted 12 lines · Greg KH

Quoted 6 lines · Pavan Kondeti

Hi

I am working on adding USB device tree support for MSM platform.  One of our chip set has 2 hsusb cores. The first core is configured as otg and the other core is configured in host only mode (EHCI compliant). Are the below device node names Okay? Please suggest.

Why do you need to name the speed of the device and the host?  That doesn't really matter if you plug a low-speed device into that super speed host controller, right?

Quoted 3 lines

I'm not familiar with device tree naming conventions, but is this something you do for network devices?  If not, I'd not recommend it for USB controllers either.

I'd like to comment, but I wasn't cc'd on the original email so I don't know what is being proposed.  Pavan, can you please resend your question and cc devicetree-discuss and me?

Quoted 6 lines · Pavan Kondeti

Hi

I am working on adding USB device tree support for MSM platform. One of our chip set has 2 hsusb cores. The first core is configured as otg and the other core is configured in host only mode (EHCI compliant). Are the below device node names Okay? Please suggest.

Why do you need to name the speed of the device and the host? That doesn't really matter if you plug a low-speed device into that super speed host controller, right?

I'm not familiar with device tree naming conventions, but is this something you do for network devices? If not, I'd not recommend it for USB controllers either.

Hi

I am working on adding USB device tree support for MSM platform.  One of our chip set has 2 hsusb cores. The first core is configured as otg and the other core is configured in host only mode (EHCI compliant). Are the below device node names Okay? Please suggest.

hsusb0-otg: usb@0xa6000000 {
       compatible = "qcom,hsusb-otg";
       ---
};

hsusb0-device: usb@0xa6000000 {
       compatible = "qcom,hsusb-device";
       ---
};

hsusb0-host: usb@0xa6000000 {
       compatible = "qcom,hsusb-host", "usb-ehci";
       ---
};

hsusb1-host: usb@0xa6000000 {
       compatible = "qcom,hsusb-host", "usb-ehci";
       ---
};

/* super speed support

ssusb0-device: usb@0xa6000000 {
       compatible = "qcom,ssusb-device";
};

Quoted 27 lines · Pavan Kondeti

Hi

I am working on adding USB device tree support for MSM platform. One of our chip set has 2 hsusb cores. The first core is configured as otg and the other core is configured in host only mode (EHCI compliant). Are the below device node names Okay? Please suggest.

hsusb0-otg: usb@0xa6000000 {
       compatible = "qcom,hsusb-otg";
       ---
};

hsusb0-device: usb@0xa6000000 {
       compatible = "qcom,hsusb-device";
       ---
};

hsusb0-host: usb@0xa6000000 {
       compatible = "qcom,hsusb-host", "usb-ehci";
       ---
};

hsusb1-host: usb@0xa6000000 {
       compatible = "qcom,hsusb-host", "usb-ehci";
       ---
};

Quoted 5 lines

/* super speed support

ssusb0-device: usb@0xa6000000 {
       compatible = "qcom,ssusb-device";
};

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.

The label names (hsusb*-host, hsusb*-device) are completely irrelevant since Linux never sees them. Use whatever you want for the label names.

Also, the form of the node name is: "usb@a6000000" (without '0x' in the address).

Quoted 8 lines · Grant Likely

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?

Quoted 5 lines

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.

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.

Hi

Quoted 8 lines · Grant Likely

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.

Quoted 5 lines

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.

Currently we have two platform devices one for OTG and one for host, corresponding drivers for them. If I would like to keep it this way, the device tree becomes something like below

hsusb0-otg: usb-otg@0xa6000000 {
       compatible = "qcom,hsusb-otg";
       ---
};

hsusb0-device: usb-gadget@0xa6000000 {
       compatible = "qcom,hsusb-device";
       ---
};

hsusb0-host: usb@0xa6000000 {
       compatible = "qcom,hsusb-host", "usb-ehci";
       ---
};

Are you okay with above naming convention?

--
Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Quoted 32 lines · Pavan Kondeti

Hi

Quoted 8 lines · Grant Likely

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.

Quoted 5 lines

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.

Currently we have two platform devices one for OTG and one for host, corresponding drivers for them. If I would like to keep it this way, the device tree becomes something like below

hsusb0-otg: usb-otg@0xa6000000 {
       compatible = "qcom,hsusb-otg";
       ---
};

hsusb0-device: usb-gadget@0xa6000000 {
       compatible = "qcom,hsusb-device";
       ---
};

Quoted 4 lines

hsusb0-host: usb@0xa6000000 {
       compatible = "qcom,hsusb-host", "usb-ehci";
       ---
};

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.

There does not need to be a device tree node for every struct device in the kernel.