On 06/10/2012 08:57 PM, Mark Brown wrote: > On Fri, Jun 08, 2012 at 10:24:06PM -0600, Stephen Warren wrote: >> On 06/08/2012 09:06 PM, Mark Brown wrote: > >>> If we're going to do this we need to update all the existing DT bindings >>> for drivers that use single node regulators like this. Please also >>> change the name used for the property to regulator-compatible to make it >>> clear that the idea is the same as normal compatible properties. > >> I'm not sure of the logic behind naming the property >> "regulator-compatible"; the standard compatible property identifies that >> the node is of a particular type/class, whereas the regulator-id in the >> example Laxman quoted would indicate the specific identity/object. Those >> seem like different things. > > They're both doing the same thing - up until you get the second register > compatible device a compatible binding is referencing a specific thing > too. It's just saying "handle this like an X". I believe there's a big semantic difference here. For every node with compatible="foo", you find a driver for "foo" and instantiate it. This will work for any number of nodes with that compatible value. The nodes are completely independent and there are no particular requirements re: what the parent of those nodes are, beyond being a bus of an appropriate type such as any old I2C bus. However, with the regulator identifiers, it's almost exactly the opposite: * There's no generic "search all busses in the system for this regulator type", but rather once a particular type of regulator chip gets instantiated, that chip's HW design defines which specific regulators it contains, and nodes for those regulators may exist as children of the regulator chip itself, and nowhere else. The individual driver is then going to look for child nodes with specific regulator-id/regulator-compatible values, not some arbitrary centralized table of possible values. * Each regulator-id/regulator-compatible value identifies a specific individual regulator within the chip that contains it. There is only one of each named regulator, since that's what exists in HW. So, this is about configuring HW that we know exists (because it's part of the HW represented by the parent node for the chip) rather than defining which HW is present on unprobeable busses, as the device-level compatible does. Given those differences, I really think that using "compatible" in the name of the property is just going to cause confusion. -- 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
