USB Configfs in Device Tree

I would like to know what exactly is the below stated is trying to convey.

To speed up the boot process by configuring USB statically in the device tree instead of it being conventionally done through a script at boot time.
Goal: USB configfs in device tree such that they can be configured statically in device tree ahead of boot and speed the boot process.

Link - BeagleBoard/GSoC/Ideas-2021 -

My Doubt - What is the meaning of USB configfs ? I haven’t came across such terminology. I know device trees are useful in configuration of non-discoverable peripherals on the board but what has configfs have to do with it? Now that combined with USB configfs is really confusing.

Past Discussion - [GSoC 2019 Project Proposal] USB configFS in device tree - #3 by jmarek

So, configfs is pretty cool, ram based filesystem with sysfs’s functionality…

When we load libcomposite on bootup, and setup our USB gadget driver thru “configfs”, you’ll notice it’s a very similar structure layout to something that “could be” easily done in a device-tree. So the idea with this GSOC project, is to create a device-tree node that could specify the USB gadget thru libcomposite on bootup. Thus users of USB gadget wouldn’t have to rely on custom boot scripts or libusbgX…


1 Like

That clears a lot of doubts. Thank You for the swift reply.

PS, here is our messy boot script:

The idea, would be to create a device-tree that does that exact same procedure.


1 Like

FYI, Device Tree is for describing the hardware, not for configuration (so implementing this using device tree would probably not be accepted in the mainline Linux kernel). I would suggest looking at Boot Configuration — The Linux Kernel documentation instead of device tree.

1 Like

I have went through both the suggestions. I agree with @dlech (Being a newbie all I did was to go through articles and docs and the statement fits) that Device trees are not intended for configuration. However in this case of adding the USB gadget node , there’s a thin boundary between configuration and description.
For ex. by adding IDs (product and vendor) , I would be describing it whereas while adding strings of function instances I would have been configuring it. (These are a newbie’s thoughts , please correct me wherever I am wrong)
So I might have two things to consider (of course with your suggestions):

  1. To make a dtsi file that contains a generic cdc node as suggested by @RobertCNelson and add more properties to it in the board specific file
  2. To use bootconfig
    For the first case I will need to go through device tree bindings and write a generic node and in the board config i would add more properties and values to it.
    For the 2nd case , I am unclear of how the key value pairs would be used. If procfs is the solution in this case then there won’t be any difference.