Hi Greg, > On May 13, 2015, at 14:52 , Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, May 13, 2015 at 10:59:44AM +0300, Pantelis Antoniou wrote: >> Document the beaglebone's capemgr sysfs API >> >> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >> --- >> .../testing/sysfs-devices-platform-bone_capemgr | 63 ++++++++++++++++++++++ >> 1 file changed, 63 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr b/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr >> new file mode 100644 >> index 0000000..e2df613 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr >> @@ -0,0 +1,63 @@ >> +What: /sys/devices/platform/bone_capemgr/slots >> +Date: May 2015 >> +KernelVersion: 4.0 > > I don't think that version is correct :) > Bah, ++ >> +Contact: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >> +Description: >> + READ: >> + Describe the state of all the slots of the beaglebone capemgr. >> + Each line of the output describes a slot: > > sysfs files are "one value per file", so a sysfs file that displays > multiple lines like this is not allowed at all, sorry. > > Please either make it a debugfs file (if this is only for debugging, or > split it out into individual files, one per slot (hint, one per slot is > probably best.) > Well, it’s a status file. And it’s been used as is for a couple of years so it was worth a shot for backward compatibility. >> + The slot format is as following: >> + <slot-id>: [P-][F-][O-][l-][L-][D-] \ >> + <overlay-id> <board-name>,<version>, >> + <manufacturer>,<part-number> >> + >> + Where the flags are: >> + P: Slot has been probed >> + F: Slot has failed probing (i.e. no EEPROM detected) >> + O: Slot has been overridden by the user >> + l: Slot is current loading >> + L: Slot has completed loading and is ready >> + D: Slot has been disabled >> + >> + Example: >> + 0: P---L- -1 BeagleBone RS232 CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03 >> + 1: PF---- -1 >> + 2: PF---- -1 >> + 3: PF---- -1 >> + >> + WRITE: >> + Writing a string of the form <part-number>[:version] issues a request to >> + load a firmware blob containing an overlay. The name of the firmware blob >> + is <part-number>-[version|00A0].dtbo. This act is defined as a slot override. >> + >> + Writing a negative slot id removes the slot if it was an overridden one, or >> + unloads a slot that was probed. >> + >> +What: /sys/devices/platform/bone_capemgr/baseboard/<eeprom-field> >> +Date: May 2015 >> +KernelVersion: 4.0 >> +Contact: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >> +Description: Contains the probed base board EEPROM field; one of: >> + board-name - board-name as stored in cape EEPROM >> + dc-supplied - whether the cape draws or supplies DC >> + eeprom-format-revision - EEPROM format rev, only 00A0 supported >> + header - header; should be 'aa 55 33 ee' > > If it's always this value, why have the file? > These are the contents of the EEPROM. If the format of the EEPROM changes then the header information will change. >> + manufacturer - manufacturer string >> + part-number - part-number of the cape >> + serial-number - serial number of the cape >> + version - version of the cape, i.e. 00A0 >> + number-of-pins - displayed but ignored >> + pin-usage - displayed but ignored >> + sys-5v - displayed but ignored >> + vdd-3v3exp - displayed but ignored >> + vdd-5v - displayed but ignored > > Are these all individual different files? > Yes >> +What: /sys/devices/platform/bone_capemgr/slot-<n>/<eeprom-field> > > No blank line? > OK >> +Date: May 2015 >> +KernelVersion: 4.0 >> +Contact: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >> +Description: Contains the probed cape's EEPROM field; the field is one of: >> + board-name - baseboard name i.e. A335BNLT >> + header - header; should be 'aa 55 33 ee' >> + revision - baseboard revision >> + serial-number - baseboard serial number >> + config-option - displayed but ignored > > Same here, are these all individual files? > Yes. > thanks, > > greg k-h Regards — Pantelis -- 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
