On Tue, Oct 20, 2015 at 4:02 PM, Pantelis Antoniou <pantelis.anton...@konsulko.com> wrote: > Hi Rob, > >> On Oct 20, 2015, at 23:56 , Rob Herring <robherri...@gmail.com> wrote: >> >> On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou >> <pantelis.anton...@konsulko.com> wrote: >>> Documentation ABI entry for overlays sysfs entries. >>> >>> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com> >>> --- >>> .../ABI/testing/sysfs-firmware-devicetree-overlays | 40 >>> ++++++++++++++++++++++ >>> 1 file changed, 40 insertions(+) >>> create mode 100644 >>> Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>> >>> diff --git a/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>> b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>> new file mode 100644 >>> index 0000000..adc4068 >>> --- /dev/null >>> +++ b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays >>> @@ -0,0 +1,40 @@ >>> +What: /sys/firmware/devicetree/overlays/ >>> +Date: October 2015 >>> +Contact: Pantelis Antoniou <pantelis.anton...@konsulko.com> >>> +Description: >>> + This directory contains the applied device tree overlays of >>> + the running system, as directories of the overlay id. >>> + >>> + enable: The master enable switch, by default is 1, and when >>> + set to 0 it cannot be re-enabled for security >>> reasons. >>> + >>> + The discussion about this switch takes place in: >>> + >>> http://comments.gmane.org/gmane.linux.drivers.devicetree/101871 >>> + >>> + Kees Cook: >>> + "Coming from the perspective of drawing a bright line >>> between >>> + kernel and the root user (which tends to start with >>> disabling >>> + kernel module loading), I would say that there at least >>> needs >>> + to be a high-level one-way "off" switch for the interface so >>> + that systems that have this interface can choose to turn it >>> off >>> + during initial boot, etc." >>> + >>> +What: /sys/firmware/devicetree/overlays/<id> >>> +Date: October 2015 >>> +Contact: Pantelis Antoniou <pantelis.anton...@konsulko.com> >>> +Description: >>> + Each directory represents an applied overlay, containing >>> + the following attribute files. >>> + >>> + can_remove: The attribute set to 1 means that the overlay >>> can >>> + be removed, while 0 means that the overlay is >>> being >>> + overlapped therefore removal is prohibited. >>> + >>> +What: /sys/firmware/devicetree/overlays/<id>/<fragment-name>/ >>> +Date: October 2015 >>> +Contact: Pantelis Antoniou <pantelis.anton...@konsulko.com> >>> +Description: >>> + Each of these directories contain information about of the >>> + particular overlay fragment. >>> + >>> + target: The full-path of the target of the fragment >>> -- >> >> What happened to attributes within the fragment dir? >> > > There’s a single attribute named target that contains the target of the > fragment. > > At the moment this is the only attribute. I eventually intent to put the full > contents of the overlay fragment > there as /sysfs/firmware/devicetree/base does, but this would make things > quite complicated for now. > > Should I add a What: line for that too?
There should be an entry for every file. These should not be in the description. So "enable" and "can_remove" need entries too. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
