On 3/13/2013 2:43 PM, Rob Herring wrote: > On 03/13/2013 05:48 PM, Mitch Bradley wrote: >> On 3/13/2013 11:33 AM, Thierry Reding wrote: >>> On Wed, Mar 13, 2013 at 10:58:02AM -1000, Mitch Bradley wrote: >>> [...] >>>> In this case, the answer to "what does pcie_controller do?" is "it >>>> implements a PCI bus" below. So 'device_type = "pci"' is appropriate. >>> >>> Alright, that's 2 against 1. I don't have much of a choice but to yield. >> >> All issues of "voting" aside, 'device_type = pci' is what tells >> of_get_pci_address() to use the 3/2 interpretation. So if you want a >> node to implement 3/2 addresses, it must say device_type = pci, unless >> you do address translation some other way. > > I should note that device_type is used for OF, but is supposed to not be > used for FDT as matching against compatible properties is preferred. I > don't have a good reason as to why, but Mitch may know the history. > However, there are numerous exceptions to that for compatibility and to > work with existing s/w. So this may be one of those cases. Indeed. The history is that, originally, the "name" property was supposed to be a very precise name, like what is now the most specific part of "compatible". And "device_type" was "what, in general, does this device do". But with rule, pathnames quickly became unusable to humans: /marvell,mv87230/marvell,svxyz/adaptec,12345/wd,8876 What the heck is that? Model names are like hashes; they have no rhyme or reason and humans cannot remember them for long. In order for a random person to have a clue about what something was, it was much better for pathname components to represent the generic function: /pci/pci/scsi/disk Now it's clear that we are looking at a bridged PCI domain hosting a SCSI disk. That's very useful for a system administrator; the gobbledygook name is not. Furthermore, in light of the facts that model numbers change much more rapidly than programming interfaces, companies clone each others programming interfaces, and companies change their names, a much more capable way of describing programming models was needed. So the "generic names" recommended practice changed things to make "name" mean what "device_type" used to vaguely mean, "device_type" was deprecated (it was never very precisely defined, and mutually-conflicting usage patterns had developed), and "compatible" in its present form was introduced. "Generic names" was quite controversial at the time - I think David Kahn wanted to strangle me at one point - but it was the right thing. (Not to mention the embarrassing mistake of the underscore in device_type, mea culpa.) That being the case, I personally would like for device_type to disappear forever. But the fact exists that address.c currently uses it (and fdt.c duly parses it), which I why I said that, if you want to use of_get_pci_address() in its present form, device_type=pci must be present in the bus node that implements the 3/2 address domain. So, yeah, it's compability with existing s/w, namely the PCI support in address.c . > > Rob > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
