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? > Rob Regards — Pantelis -- 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
