Updates

onlp/applications/apis.md

@@ -14,4 +14,3 @@
 
 ## System APIs
 * [Platform Management](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/applications/platform)
-* [Debug](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/applications/debug)

onlp/applications/attributes.md

@@ -1 +1,31 @@
 # Attributes
+
+The OID Attribute API provides a generic mechanism to get or set key/value pairs on any object.
+
+## The Attribute API
+
+You can perform the following operations using this API:
+* Ask an OID if it supports the given named attribute.
+* Ask an OID to return the value of a named attribute.
+* Ask an OID to set the value of a named attribute.
+* Ask an OID to free a previously returned attribute.
+
+## Standard Attributes
+
+The attribute keys and values are system and implementation specific.
+The API does however define two standard attributes that should be supported if possible:
+
+### The ONIE Attribute
+The ONIE attribute should return the ```onlp_onie_info_t``` structure.
+At a minimum this is supported by the Chassis OID to return the system identification information.
+Any OID that has an ONIE identifier (for example a pluggable module) should also support this attribute.
+
+### The Asset Attribute
+The ONIE information structure is defined by the available TLV values defined in the ONIE [specification](https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html)
+
+The fields of the ```onlp_asset_info_t``` structure are defined by the ONLP API and evolve over time.
+This attribute should be implemented at a minimum by the Chassis OID to return important system information (like firmware revisions).
+
+## Attribute Documentation
+* [Doxygen](https://htmlpreview.github.io/?https://raw.githubusercontent.com/opencomputeproject/OpenNetworkLinux/ONLPv2/packages/base/any/onlp/src/onlp/doc/html/group__attributes.html)
+* [Header](https://github.com/opencomputeproject/OpenNetworkLinux/blob/ONLPv2/packages/base/any/onlp/src/onlp/module/inc/onlp/attribute.h)

onlp/applications/concepts.md

@@ -8,7 +8,8 @@ The ONLP Application API manages the following types of platform objects:
 * PSUs
 * Thermals Sensors
 * LEDs
-* Other Customized Platform Entities
+* Hot Swapped Modules
+* Private/Custom features.
 
 Platform objects in the ONLP API are represented as handles called Object IDs (OIDs). OIDs have both common and type-specific status, capabilities, and attributes.
 
@@ -23,7 +24,7 @@ There are functionality-specific APIs defined for each OID subtype.
 
 ## OID Representation
 
-OIDs are just 32 bit integer handles. The most significant byte of the OID encodes the type (SFP, FAN, PSU, etc). The remaining 3 bytes are a unique id referencing a platform-defined object (like Fan 1, Fan 2, Fan 3, etc).
+OIDs are just 32 bit integer handles. The most significant byte of the OID encodes the type (SFP, FAN, PSU, etc). The remaining 3 bytes are a unique id referencing a platform-defined object (like Fan 1, Fan 2, Fan 3).
 The code that defines and manipulates OIDs can be found [here](https://github.com/opencomputeproject/OpenNetworkLinux/blob/ONLPv2/packages/base/any/onlp/src/onlp/module/inc/onlp/oids.h)
 
 

onlp/applications/debug.md

@@ -1 +0,0 @@
-# Debug

onlp/applications/platform.md

@@ -1 +1 @@
-# Platform
+# Platform Management

onlp/applications/sfp.md

@@ -1 +1,32 @@
-# SFPs
+# SFP Management
+
+## SFP OIDs
+
+Each SFP OID represents a small form factor pluggable module. When an SFP OID is present then a module is plugged in. When an SFP OID is absent then the port is empty.
+
+## SFP Information Structure
+Information about the current module is queried using ```onlp_sfp_info_get``` to populate the ```onlp_sfp_info_t``` structure.
+
+There are several useful fields in this structure:
+* The physical form factor of the port - SFP+,QSFP+,SFP28,QSFP28,QSFP-DD
+* The status of the external signal (depending upon module type) - TX_DISABLE, LP_MODE, RX_LOS, and others.
+* The identification of the given module based on the SFF MSA standards
+* The Digital Optical Monitoring data based on the SFF MSA standards.
+
+## SFP APIs
+
+While calling ```onlp_sfp_info_get``` is sufficient to identify the inserted module there are several operational APIs provided to manage it.
+
+* Change the control signal status
+** Enable TX_DISABLE
+** Disable LP_MODE
+* Generic Read/Write Operations
+** Perform I2C byte and word reads on the given module (any device address).
+
+## SFP Documentation
+
+* [Doxygen](https://htmlpreview.github.io/?https://raw.githubusercontent.com/opencomputeproject/OpenNetworkLinux/ONLPv2/packages/base/any/onlp/src/onlp/doc/html/group__oid-sfp.html)
+* [Header](https://github.com/opencomputeproject/OpenNetworkLinux/blob/ONLPv2/packages/base/any/onlp/src/onlp/module/inc/onlp/sfp.h)
+
+---
+[Return to APIs](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/applications/apis)