Device trees I: Are we having fun yet?

There is a way to define USB devices on a USB bus in device trees, just as there are bindings to present PCI devices on a PCI bus which is intended to be "discovered" by the OS.

There definitely should be a little standardization around it - imagine a platform where USB ports are present but also parts are soldered to the PCB. They will *always* appear at the same places in the USB topology.

PCI device "compatible" properties are usually derived from the device and vendor ids (and sub ids) in the configuration space. USB has much the same thing. If you ever enabled dynamic network device naming on a modern Linux kernel, it is much the same gobbledegook string - v8081d1504u8181s8171.

If it is fixed to the board, then it should be fixed in the tree. And sometimes, hubs and other USB devices need configuring to tell them they're fixed to a board and their ports are not hot-pluggable.

For a dynamic firmware implementation that can generate a device-tree on the fly (more relevant on PowerPC than ARM, but there is no reason it cannot happen on ARM), it is still expected that it would fill in /chosen properly in the final device tree for things like it's boot device. In this case, a USB device has to be present in the tree to be referenced by phandle.

For WiFi and suchlike, it is acceptable that a 'pretend' rfkill node might be created to control the devices and follow the Linux subsystem, but this would go against the OS-neutrality of device trees. In this case, the solution is simple. If it is soldered down or shipped as a fixed option in a consumer device (such as in a Netbook, under a door you may remove but wouldn't want to remove the warranty sticker to do so) then it should be listed.