On Friday 18 March 2011, Andy Green wrote:
On 03/17/2011 10:33 PM, Somebody in the thread at some point said:
quoted
On Thursday 17 March 2011 22:47:36 Greg KH wrote:
quoted
Well, that means that the device tree work is going to be useful here,
right? :)
I like the idea. Let's make this the first use case where a lot of
You changed your first opinion about tagging "dynamically probed
devices" with what is effectively platform_data, cool.
I still don't like the idea of attaching platform_data to more
devices, when we try to move people away from that in other
parts of the kernel, because of the known deficiencies.
Passing a MAC address in a device tree property is a
well-established method that is used on many drivers, and
is portable across operating systems and architectures.
quoted
people will want to have the device tree on ARM. The patch to the
driver to check for a mac-address property is trivial, and we
can probably come up with a decent way of parsing the device
tree for USB devices, after all there is an existing spec for
it (http://playground.sun.com/1275/bindings/usb/usb-1_0.ps).
It doesn't do it already then.
That spec you pointed to from 1998 is obviously going to be a whole
subproject doing the binding, it seems to fingerprint devices by VID/PID
if I understood it.
We don't need to implement the entire binding. My point was that
if we implement a way to attach a device_node to a usb_device, we
should do it in a way that is compatible with that binding, rather
than coming up with a new way.
Most importantly, you can ignore the entire "compatible"-
and "name"-property matching. I think we only need to look
at the "reg" property to walk the bus structure, and any
usb_device we find during the USB hub probing simply gets
linked to its device_node.
What's the plan for leveraging that level of generality on "dynamically
probed devices"? I mean I know what I want to use this for and the
platform_data scheme covers all the soldered-on-the-board cases fine.
Isn't there also a device tree based OMAP tree that can boot on
Panda and is just waiting to get merged?
Is there actually a need for sort of not platform_data but universal
vid_pid_specific_usb_device_option_data coming from the board definition
file or bootloader for *pluggable* usb devices? udev seems to be well
established doing that already in a generic, not-platform-specific way
that can go in all distros and so on nicely. Maybe this is just my
impoverished imagination and people do want, say, some kinds of USB mice
to operate at higher DPI or whatever when plugged in a specific board
because it is that board.
It should really not be tied to a specific board, and there is a lot
of work going on to remove the need for board-specific source code
files, replacing it all with data structures.
My impression so far is that attaching a struct device_node to
static USB devices can be useful in general, but I wouldn't
go so far to suggest using this for dynamically probed devices.
Arnd