Hi Rob,
On Oct 20, 2015, at 23:56 , Rob Herring [off-list ref] wrote:
On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou
[off-list ref] wrote:
quoted
Documentation ABI entry for overlays sysfs entries.
Signed-off-by: Pantelis Antoniou <redacted>
---
.../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.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
+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.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
+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.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
+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