On Mon, 8 Oct 2012, Tony Prisk wrote: > My biggest concern about the binding is all the platform_data that is > used in the ehci-platform driver that I don't recognise. > arch-vt8500 doesn't require any of them. > > Looking through, most seem like they would be obvious candidates for DT > properties: How does DT handle IP-specific quirks? Does it always introduce special properties to represent them? > has_tt > has_synopsys_hc_bug > big_endian_desc > big_endian_mmio > port_power_on > port_power_off Certainly has_tt, big_endian_desc, and big_endian_mmio are candidates for DT properties. The port_power things can be ignored; I am going to remove them eventually anyway. has_synopsys_hc_bug is an example of a quirk like I mentioned above. > These function pointers can't be passed as DT properties, and I don't > know what to do with them (or how to handle them other than excluding > them from DT-probed devices). > power_on > power_off > power_suspend How does DT handle power management in general? Don't different platforms and boards have differing requirements? > I don't know alot about the ehci-platform driver and/or its users, so I > was reluctant to mess around with it for 3.7 in case it held up the rest > of my patchset. ehci-platform is intended to be a general-purpose driver for EHCI platforms that don't require much special treatment. The platform_data information describes the systems' varying requirements; aside from that everything is handled in a very generic way. Ignoring it for 3.7 is fine, but I definitely would like to use it in as many places as possible in future releases. Alan Stern -- 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
