On 11/08/2011 05:06 AM, Somebody in the thread at some point said:
On Mon, Nov 07, 2011 at 10:44:23PM +0800, Andy Green wrote:
On 11/07/2011 10:35 PM, Somebody in the thread at some point said:
On 6 November 2011 22:28, Grant Likelygrant.likely@secretlab.ca wrote:
On Sun, Nov 6, 2011 at 3:09 AM, Thomas Abraham thomas.abraham@linaro.org wrote:
Hi Grant,
On 5 November 2011 00:50, Grant Likelygrant.likely@secretlab.ca wrote:
Proof of concept, needs to be made compilable and add the unwind path on error and remove.
Bodged-together-by: Grant Likelygrant.likely@secretlab.ca
Is there is reason to include device nodes in dts file for usb devices that are attached to a usb host? What additional information would such nodes include apart from the device information obtained during enumeration?
There are cases where soldered down USB devices on the mainboard will have additional connections that cannot be discovered by the driver. GPIOs for instance, or an Ethernet device that needs to be assigned a MAC address.
Thanks Grant. Does that imply that there has to be additional code in other places which will actually use the information available in the attached device node. In the example of MAC address for ethernet device, the logic to lookup and use the MAC address might have to be added to cdc/rndis layers.
Also, would the matching of device node on 'udev->portnum' be consistent each time. There could different devices connected at boot time to the host port or there could be no devices connected. To ensure that udev->portnum matches each time, there might have to be additional restrictions on the hub port to which the soldered USB devices are connected.
As far as I understand it, the portnum value should be stable for soldered down devices (as opposed to the devnum address which is dynamically assigned). As far as I've explored, the USB DT binding requires that the hub topology be directly reflected by the DT topology, and that each portnum value is directly associated with the port number on the parent hub device or root controller.
This of course only makes sense for soldered down devices which are always present. It makes zero sense to describe removable devices in a static device tree.
However DT is recognizing the device is being probed differently, it will still need to do something similar on device recognition to actually scratch the "no MAC" itch.
Yes, the driver (or possibly a helper function in etherdevice.h) will need to extract the mac address if the node pointer is set. However, in this case, there is no need to change the way that the driver gets probed. USB already provides all the details required to reliably select a driver.
Right I also think there won't be any problem with mapping or stability of mapping for DT implementation for this, since the existing code using the USB device "path" is effectively matching on the exact same underlying data and that has been reliable for this purpose.
I don't really understand best approach to deliver what is a computed MAC this way though, if some kind of callback can be triggered to compute and set it at probe time that'd be fine, or if some code could run first and find and force the MAC value in DT table that'd work too. It's not really preferable to do it in bootloader.
-Andy