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.
Panda Ethernet is a consumer of this code. At the moment I solved MAC address generation by computing it from what's meant to be a GUID in the CPU ID register, and rolled my own deferred device probing code, since DT-based solution showed no sign of existing until last week.
You can see the working business end of that code here -->
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=patch... http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=patch...
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.
-Andy