On 21.05.2012 16:58, Thierry Reding wrote: > I agree that reflecting the hardware hierarchy within the device tree makes > sense. I'll need to add some code to tear down child devices in the cleanup > path, but that shouldn't be too difficult. > > However, adding a whole bus_type implementation would pretty much duplicate > the platform bus code. I guess host1x could just provide struct host1x_client > a set of corresponding APIs to create them, request channels, etc. Hi, There is a reason for existence of bus_type in Linux kernel. It exposes the various busses to developers, and give a framework for drivers to work in. It just makes the drivers easier to develop, and makes the big picture easier to understand. The problem is that bus_type is cumbersome to implement, and most implementations seem to duplicate significant amount of code from platform bus. This is the problem that we should tackle. If I manage to get the boilerplate code in nvhost for bus_type small enough, that's the structure we should use. If bus_type is just inherently fat and broken, I'll need to migrate nvhost away from it. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
