[PATCH] totally untested attachment of device nodes to usb devices

Andy Green andy.green at linaro.org
Mon Nov 7 14:44:23 UTC 2011


On 11/07/2011 10:35 PM, Somebody in the thread at some point said:
> On 6 November 2011 22:28, Grant Likely<grant.likely at secretlab.ca>  wrote:
>> On Sun, Nov 6, 2011 at 3:09 AM, Thomas Abraham
>> <thomas.abraham at linaro.org>  wrote:
>>> Hi Grant,
>>>
>>> On 5 November 2011 00:50, Grant Likely<grant.likely at secretlab.ca>  wrote:
>>>> Proof of concept, needs to be made compilable and add the unwind path
>>>> on error and remove.
>>>>
>>>> Bodged-together-by: Grant Likely<grant.likely at 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;a=patch;h=81460407088b10e33af516738a9ffc7bd0b3fb0f
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=patch;h=d1dba63ca89ddac278e23bda190122188c85266d

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

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog



More information about the linaro-kernel mailing list