On 26.06.2012 20:46, Stephen Warren wrote: > I'd certainly like to see some upstream discussion re: why exactly we > have a custom bus type here. What does it do that a regular platform bus > doesn't do? Are those features something that would be generally useful > to add to the existing platform bus? Can we instead add hooks into > platform bus rather than creating a new bus? I recall you saying that > the nvhost_bus duplicated a lot of code from the existing platform bus. Yes, the code is largely a copy of platform bus. One big difference is type safety - all the nvhost_bus APIs take in and give out nvhost_device or nvhost_driver pointers. At the registration time I also enforce parent-child relationship to host1x and bus clients. Another is that I am able to enumerate all host1x related devices. The latter could of course be done via listing the children of host1x. And third is that I was able to add version field to device to distinguish between Tegra2 and Tegra3 3D (for example) and make the bus use that information for binding driver and device. As the sysfs entry path is determined by the device name, this allows keeping the old sysfs APIs. As you can see, most of the reasons are more related to convenience than own bus_type being the only way to implement them. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html