On Sun, 2012-10-07 at 21:47 -0400, Alan Stern wrote: > On Mon, 8 Oct 2012, Tony Prisk wrote: > > > > How about instead of changing ehci-vt8500.c, remove it completely and > > > use ehci-platform instead? The changes required should be minimal, > > > especially after ehci_update_device() get moved into ehci-lpm.c and > > > added to the hc_driver structure for ehci-platform.c. > > > > > > Alan Stern > > > > The main reason I used ehci-vt8500.c is that it works at the moment, and > > this was supposed to be a bug-fix. > > > > I agree that we should be using -platform, but it currently doesn't have > > a DT binding, so it's unlikely that I could get a binding formalized and > > the changes made to fix the current issue for 3.7 > > Okay, but what would be needed to start the process rolling? It may > not be too late for 3.8... > > Alan Stern 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: has_tt has_synopsys_hc_bug big_endian_desc big_endian_mmio port_power_on port_power_off 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 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. Regards Tony P -- 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
