Tomasz, On Thu, Dec 5, 2013 at 10:59 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: > On Thursday 05 of December 2013 10:35:20 Doug Anderson wrote: >> Tomasz, >> >> On Thu, Dec 5, 2013 at 10:30 AM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: >> >> I'd vote for using "pmu-system-registers". We end up using the >> >> "syscon" subsystem but really we're describing pmu registers. >> >> >> >> I'd even say that you don't need to formally specify the "name" in the >> >> bindings (though I'm not up with all the latest device tree >> >> requirements). ...still you'd want to use "pmu-system-registers" in >> >> the DTS changes. >> > >> > Well, since the name should specify the class of device, I would say that >> > pmu-system-registers is too specific. If we want to change this, I'd say >> > we should go with system-controller. >> >> ...but the "compatible" is "samsung,exynos5250-pmu", "syscon", right? >> That means that the class of the device is "exynos5250-pmu", right? > > Nope. "samsung,exynos5250-pmu" is the specific device (or hardware > programming interface) this device is compatible with. > > With class I mean the generic kind of device, such as system-controller, > i2c, pinctrl, display, etc., as specified by sections 2.2.1 and 2.2.2 of > ePAPR. > > Anyway, node names are just a matter of coding style, as they don't have > any semantical meaning in most cases (such as this one). > >> It is also compatible with the generic "syscon" class of devices. > > It is also compatible with the generic "syscon" programming interface, > which represents a set of loosely related registers that control various > aspects of other IP blocks. OK. I will certainly cede to your superior knowledge of device tree conventions. Leela Krishna: unless someone else comes up with a convincing argument, it sounds like the dts files should have the name "system-controller" and the bindings change should remove all references to the name. -Doug -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html