On Friday 18 March 2011, Andy Green wrote: > On 03/17/2011 10:33 PM, Somebody in the thread at some point said: > > On Thursday 17 March 2011 22:47:36 Greg KH wrote: > >> > >> 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
