On Thu, 25 Aug 2011, Arnd Bergmann wrote: > It's not at all about whether the Linux codein drivers/of supports this > or not, adding it would be trivial. The point is that it would be > *wrong* to add it because there already exists a way to identify every > resource in the device tree and we should not extend that interface > to have multiple ways to do the same thing just for convenience of > a few device drivers! The point is that: - there was a reason why platform_get_resource_byname() was added to the Linux kernel, that at least some people find useful and relevant - some folks are effectively proposing to remove platform_get_resource_byname() not because it's a bad interface, but because it would result in changes to the way that DT files are generated and used Just as you consider the preservation of platform_get_resource_byname() to be wrong (because it conflicts with DT), some people consider the above rationale to be faulty, because it removes a useful way to abstract drivers from SoC data. For example, consider that the ordering of device resources, such as IRQ lines or memory regions, in the hardware IP block is arbitrary. Whomever generates a DT file for that hardware will need to hardcode the driver's assumptions for resource order into the DT generator. And then hope that the binding assumptions made by that driver are coordinated between all of the other potential DT users out there: other OSes (proprietary or not), bootloaders, etc. Contrast this with the situation when named resources are used. The resources are named with a string that represents their use by the hardware IP block. In this situation, the order in which they appear in the DT file is unimportant. There need be no extra hacks added to the DT generation code or to the drivers to ensure that they find the correct resource. Please don't misunderstand: I personally don't consider this specific problem to be a showstopper. It makes sense to me to improve the DT format to use named resources. But if the consensus is that the problem is just going to be knowingly pushed on to the poor folks who have to generate DT files, who will have to maintain a bunch of hacks to do so, then, so be it. But the issue highlights a much larger problem: the apparent level of resistance to improving the DT data format in ways that may affect backwards compatibility. There are several aspects of DT, and the way that it's used in the kernel, that could be improved -- like, for example, the fact that computer systems for the past several years are not well-represented by a tree of devices. And if we don't have a strategy for versioning the content and the layout of the device data, as opposed to simply its binary format, then it's unwise to consider it for broader adoption until this exists, IMHO. > One of the important advantages of using the IEEE device tree bindings > is that we can define device trees that are to a large degree compatible > with how AIX, Solaris, MacOS, FreeBSD and probably many more (lesser > known) operating systems probe their systems. By that rationale, we should just use ACPI. It's far more widely deployed than all of those other OSes combined. (No, I don't think we should use ACPI.) By the way, MacOS stopped using Device Tree several years ago. > Changing the resource interface in Linux to have two 'name' fields > would also be terribly confusing and is not a good interface There are other ways of solving that particular problem, other than having two 'name' fields. > it would just solve another problem (silly entries in /proc/iomem) that > we don't need to have in the first place when we do the obvious > conversion of the drivers to the IEEE standard way of doing this. Just like MacOS, the IEEE gave up on Device Tree -- in fact, over a decade ago -- so it doesn't make sense to cite them as an authority any more. My point is not to disrespect DT, which seems like a useful way of moving device data out of the kernel tree; but rather, to try to ensure that we're not locked into a rigid and outdated way of doing things: either technically, or by people's attitudes. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
