diff --git a/doc/platform/brcm_pdk_pddf.md b/doc/platform/brcm_pdk_pddf.md
index dfa45878294..7ddca544f4f 100644
--- a/doc/platform/brcm_pdk_pddf.md
+++ b/doc/platform/brcm_pdk_pddf.md
@@ -53,6 +53,12 @@
* [SAI](#sai)
* [CLI](#cli)
* [Serviceability and DEBUG](#serviceability-and-debug)
+ * [S3IP Standard Support](#s3ip-standard-support)
+ * [S3IP PDDF Requirements](#s3ip-pddf-requirements)
+ * [Implementation Details](#implementation-details)
+ * [PDDF and S3IP SysFS](#pddf-and-s3ip-sysfs)
+ * [S3IP SysFS Creation and Mapping](#s3ip-sysfs-creation-and-mapping)
+ * [Adding S3IP Support for a Platform](#adding-s3ip-support-for-a-platform)
* [Warm Boot Support](#warm-boot-support)
* [Unit Test](#unit-test)
@@ -70,6 +76,7 @@
| 0.5 | 10/31/2019 | Fuzail Khan, Precy Lee | BMC Support |
| 0.6 | 10/01/2020 | Fuzail Khan, Precy Lee | FPGAI2C component support |
| 0.7 | 01/05/2023 | Fuzail Khan, Precy Lee | FPGAPCIe component support |
+| 0.8 | 03/17/2023 | Fuzail Khan, Precy Lee | S3IP SysFS support |
# About this Manual
Platform Driver Development Framework (PDDF) is part of SONiC Platform Development Kit (PDK), which enables rapid development of platform drivers and APIs for SONiC platforms. PDK consists of
@@ -1866,13 +1873,137 @@ root@sonic:/home/admin#
### Debug logs
All the logs can be found under /var/log/pddf.
+## 7 S3IP Standard Support
-## 7 Warm Boot Support
+S3IP sysfs specification defines a unified interface to access peripheral hardware on devices from different vendors, making it easier for SONiC to support different devices and platforms. The S3IP standard support is now available with PDDF. If the user wants, there is a provision to enable/create S3IP sysfs standards.
+
+### 7.1 S3IP PDDF Requirements
+
+- S3IP sysfs should be generated and could be removed on requirement
+- Though S3IP can be clubbed with PDDF, PDDF should be independent of the S3IP
+- If any attribute which cannot be read should have a value of 'NA' i.e. tools should not fail due to non existance of the attribute
+- S3IP sysfs should be able to work with the existing PDDF common driver sysfs
+- PDDF common driver attributes should be expanded, if required, to cover the left out attributes from S3IP specifications
+
+### 7.2 Implementation Details
+
+The S3IP specifications and framework are defined [here](https://github.com/sonic-net/SONiC/pull/1068). Both vendors and users are required to follow the S3IP spec. The platform vendors need to provide the implementation of the set/get attribute functions for the platforms which use S3IP sysfs framework. The attributes for each component are defined in the specificaitons. This effort is to combine the S3IP spec and PDDF framework. In other words, the platform which are using PDDF would be S3IP compliant too after this support is added.
+
+#### 7.2.1 PDDF and S3IP SysFS
+
+PDDF implements common kernel drivers for various components. These common drivers exposes a fixed set of sysfs attributes as per the HW support and current SONiC API requirements. Complying to S3IP spec requires the mapping of S3IP component attributes to PDDF exposed sysfs attributes and might even require adding new attributes to PDDF common driver code. Hence, S3IP spec sysfs attributes are divided into the following categories.
+
+ - Platform Info Attributes: This includes the fixed information pertaining to the platform in entirity or any component. There is no need of reading this information from the component in run time. Further, these values will not change in the course of System running the SONiC image. Below are few examples of static info attributes.
+
+ - /sys_switch/temp_sensor/number, /sys_switch/vol_sensor/number, /sys_switch/curr_sensor/number etc.
+
+ - /sys_switch/cpld/cpld[n]/alias, /sys_switch/temp_sensor/temp[n]/alias, /sys_switch/temp_sensor/temp[n]/type etc.
+
+ S3IP file system can be created and the information can be directly written from the PDDF JSON files to them. Since this is static information, there is no need of repeatedly updating it.
+
+ - Component Attributes: These are the attributes are to be read from various HW components. These could be dynamically changing information like PSU voltage and temperature, or fixed like PSU serial number or FAN model etc.
+
+ - Some such S3IP sysfs would match the sysfs exposed by the PDDF frameowrk and hence a proper mapping with softlink creation would suffice.
+
+ - Some S3IP sysfs would not match directly with PDDF exposed sysfs. For such attributes, either PDDF common dirvers can be enhanced to provide the exact match or some other method can be used.
+
+ - There are some S3IP attributes which can't and won't be mapped to common PDDF driver attributes because PDDF common code doesn't support these devices e.g. volt_sensors, curr_sensors etc. There are no PDDF common drivers for such devices. However, ODMs might extend the PDDF framework by providing the custom drivers. In such cases, ODMs need to take care of mapping the S3IP attributes to the attributes exposed by the custom drivers.
+
+ - We faced a practical issue for some S3IP attributes e.g. Fan status. S3IP description says
+
+ |Sysfs path|Permissions|Data type|Description|
+ |-|-|-|-|
+ |/sys_switch/fan/fan[n]/status |RO| enum| Fan states are defined as follows: 0: not present 1: present and normal 2: present and abnormal
+
+ - This is a combination of 'presence' and 'running_status' informations of a fan unit. In SONiC we can handle this in the platform APIs but S3IP compels to performs this processing inside the kernel modules. Hence if ODM extends the PDDF driver and provide the kernel implementation of such sysfs, we can create the mapping. Otherwise we will map it to 'NA'.
+
+#### 7.2.2 S3IP SysFS Creation and Mapping
+
+
+
+
+If the S3IP sysfs is required on a PDDF platform, it can be represented using the field "enable_s3ip" in the PDDF JSON file. If this field is not mentioned or has a value "no", then the S3IP sysfs creation is disabled for that platform. The support for S3IP is controlled by a service "pddf-s3ip-init.service". This service is run at the end of PDDF platform initialization service. It is an standalone service which needs to have an 'after' dependency on PDDF platform init service.
+```
+ "PLATFORM":
+ {
+ "num_psus":2,
+ "num_fantrays":4,
+ "num_fans_pertray":2,
+ "num_ports":64,
+ "num_temps": 8,
+ "enable_s3ip": "yes",
+ "pddf_dev_types":
+ {
+ "description":"AS7816-64X - Below is the list of supported PDDF device types (chip names) for various components. If any component uses some other driver, we will create the client using 'echo //service/pddf-s3ip-init.service b/platform/broadcom/sonic-platform-modules-//service/pddf-s3ip-init.service
+new file mode 120000
+index 000000000..f1f7fe768
+--- /dev/null
++++ b/platform/broadcom/sonic-platform-modules-//service/pddf-s3ip-init.service
+@@ -0,0 +1 @@
++../../../../pddf/i2c/service/pddf-s3ip-init.service
+\ No newline at end of file
+
+
+# ls -l platform/broadcom/sonic-platform-modules-//service/pddf*
+total 3
+lrwxrwxrwx 1 fk410167 nwsoftusers 55 May 8 02:02 pddf-platform-init.service -> ../../../../pddf/i2c/service/pddf-platform-init.service
+lrwxrwxrwx 1 fk410167 nwsoftusers 55 May 8 02:02 pddf-s3ip-init.service -> ../../../../pddf/i2c/service/pddf-s3ip-init.service
+#
+
+```
+
+Build the platform and sonic-device-data debian packages and load the build on the respective platform.
+
+
+## 8 Warm Boot Support
Platform service restart should be supported without having to reboot the device
-## 8 Scalability
+## 9 Scalability
NA
-## 9 Unit Test
+## 10 Unit Test
Generic unit tests are listed below. These should be extended to all the components where they are applicable.
1. JSON descriptor file - Schema validation and error detection
2. Test descriptor file Parsing
diff --git a/doc/s3ip_sysfs/s3ip_sysfs_hld.md b/doc/s3ip_sysfs/s3ip_sysfs_hld.md
new file mode 100644
index 00000000000..f1ed6786597
--- /dev/null
+++ b/doc/s3ip_sysfs/s3ip_sysfs_hld.md
@@ -0,0 +1,339 @@
+# S3IP sysfs specification and S3IP sysfs framework HLD #
+
+## Table of Content
+
+ * [Scope](#scope)
+ * [Definitions/Abbreviation](#definitionsabbreviation)
+ * [1. Overview](#1-overview)
+ * [2. S3IP sysfs specification](#2-s3ip-sysfs-specification)
+ * [2.1 S3IP sysfs specification scenario](#21-s3ip-sysfs-specification-scenario)
+ * [2.2 Design of the S3ip sysfs specification](#22-design-of-the-s3ip-sysfs-specification)
+ * [3. S3IP sysfs framework](#3-s3ip-sysfs-framework)
+ * [3.1 S3IP sysfs framework scenario](#31-s3ip-sysfs-framework-scenario)
+ * [3.2 S3IP sysfs framework design](#32-s3ip-sysfs-framework-design)
+ * [3.3 Porting guide](#33-porting-guide)
+
+
+### Revision
+ | Rev | Date | Author | Change Description |
+ |:---:|:-----------:|:------------------:|-----------------------------------|
+ | 0.1 | 08/16/2022 | timstian | Initial version |
+
+### Scope
+This document describes the SONiC sysfs specification and the design of the SONiC sysfs generation framework.
+
+### Definitions/Abbreviations
+| Abbreviation | Description |
+|--------------------------|---------------------------------------------------|
+| S3IP | Simplified Switch System Integration Program |
+| CPLD | Complex Programmable Logic Device |
+| I2C | Inter-Integrated Circuit |
+| SAI | Switch Abstraction Interface |
+| ODM | Original Design Manufacturer
+
+### 1. Overview
+
+SONiC is designed to be portable to a variety of network devices. Many devices share the same ASIC platform and only differ in device-specific hardware components, such as PSUs, fan modules, and environment sensors. Currently, ODM vendor provides drivers to expose the device-specific hardware through sysfs, allowing SONiC to communicate with them, as described in the [Porting Guide](https://github.com/sonic-net/SONiC/wiki/Porting-Guide). However, many inefficient porting works are still required for SONiC developers due to different drivers from different devices.
+
+The S3IP sysfs specification defines a unified interface to access peripheral hardware on devices from different vendors, making it easier for SONiC to support different devices and platforms.
+
+**Requirements for S3IP sysfs:**
+1. Should be able to work with the existing platform APIs
+2. The hierarchy of sysfs path structure should be defined in a specification.
+3. The sysfs path in the specification should be defined clearly, thus, platform API and test cases can be reused.
+4. The sysfs directory structure can be generated automatically through the framework.
+5. Support reuse of the old driver sysfs paths without redeveloping new drivers.
+
+**S3IP background Introduction**
+
+Simplified Switch System Integration Program, aka [S3IP](http://www.s3ip.org/), is the subproject of the Open Data Center Committee, aka [ODCC](http://www.opendatacenter.cn/introduction-en.html). S3IP is a joint initiative of six Internet companies in China, including Baidu, Alibaba, Tencent, Meituan, JD.com, and Kuaishou. Focusing on the network field, S3IP aims to solve the common problems in the integration process of the upper layer software and the lower layer equipment and establish a standardized ecology. The standardized design is more friendly to equipment manufacturers and enterprise users (such as the Internet), easier to integrate, more efficient to solve problems with the help of ecological forces, and faster to implement new technologies in the ecosystem.
+
+S3IP sysfs contains two sections:
+
+- sysfs specification: specifies the sysfs directory structure and file content
+- sysfs framework: generate the sysfs directory structure that conforming to the specification.
+
+### 2. S3IP sysfs specification
+#### 2.1 S3IP sysfs specification scenario
+
+Figure2-1 where S3IP sysfs is used.
+
+
+
+The S3IP sysfs specification is represented as an organized sysfs directory structure on white-box devices. Device management software and debugging tools need to access hardware through this interface.
+
+Both vendors and users should comply with the S3IP sysfs specification. Device vendors focus on the specification implementation, while users verify the usability of the device against this specification. Vendors should provide software access to every sensor capable of being read. For any available sensor, vendors shall provide S3IP sysfs access.
+
+Figure2-2 S3IP sysfs diretory demo
+
+
+
+#### 2.2 Design of the S3ip sysfs specification
+Design Principles
+ - Unified, well-specified behavior, consistent experience among all SONiC devices, regardless of underlying platform;
+ - Easy to understand, implement, test and debug
+ - The sysfs root directory must be "/sys_switch", and the directory and its subdirectories or files can be soft links. For example, it is legal to link a file from /sys to /sys_switch.
+ - The contents of files in sysfs should be generated dynamically, using the same mechanism as the file contents in the /sys path of the Linux system.
+ - Sysfs has no specific CPU architecture requirements.
+ - Each file in sysfs represents a hardware property, and the property unit should be omitted.
+ - When a switch contains multiple devices of the same type, sysfs must be uniquely identified by the natural numbers 1 to n. For example, /sys_switch/fan/fan1 represents information about fan number 1
+ - This specification defines the path name, permissions, data type, and data unit for each hardware
+ - The sysfs path defined in this specification must exist, and the file content should be "NA" if no hardware is available.
+
+S3IP sysfs specification : [specification](/doc/s3ip_sysfs/s3ip_sysfs_specification.md)
+
+S3IP sysfs specification hierarchy overview
+- sys_switch
+ - cpld
+ - number
+ - cpld1
+ - alias
+ - type
+ - ...
+ - psu
+ - syseeprom
+ - sysled
+ - transceiver
+ - temp_sensor
+ - vol_sensor
+ - cur_sensor
+ - watchdog
+ - slot
+ - fpga
+
+
+### 3. S3IP sysfs framework
+#### 3.1 S3IP sysfs framework scenario
+The goal of the S3IP sysfs framework is to make it easy for vendors to generate sysfs directory structures that conform to the S3IP sysfs specification.
+
+
+
+S3IP sysfs framework contains two parts。
+ - S3ip_sysfs_service: kernel module management, configuration file parsing and /sys_switch directory generation.
+ - S3ip_sysfs_framework: the framework kernel module.
+
+#### 3.2 S3IP sysfs framework design
+Design Principles
+ - Keep kernel modules as simple as possible.
+ - Reuse sysfs paths of existing drivers as much as possible.
+ - Easy to implement and debug.
+
+The process for creating /sys_switch/
+
+
+
+Flow to get the fan speed
+
+
+
+ the code for submission:
+ - Two device platforms that conform to the S3IP sysfs specification will be submitted to the buildimage repository
+ - S3ip sysfs framework will be submitted to the sonic-platform-common repository
+
+##### 3.2.1 s3ip sysfs kernel module
+
+The specification is not only a guideline, but also contains requirements for implementation. The kernel module is designed to make it easy to meet those details.
+
+S3IP sysfs kernel module(aka s3ip_sysfs.ko) provided the following features:
+
+1. Register/unregister mechanisms to interact with the s3ip_sysfs.ko.
+
+2. Dynamically generate/destroy the corresponding directory when a driver that uses s3ip_sysfs.ko is installed/uninstalled.
+
+Sample code for the watchdog interactive interface, The s3ip_sysfs.ko implements this code
+
+```
+struct s3ip_sysfs_watchdog_drivers_s {
+ ssize_t (*get_watchdog_identify)(char *buf, size_t count);
+ ssize_t (*get_watchdog_state)(char *buf, size_t count);
+ ssize_t (*get_watchdog_timeleft)(char *buf, size_t count);
+ ssize_t (*get_watchdog_timeout)(char *buf, size_t count);
+ int (*set_watchdog_timeout)(int value);
+ ssize_t (*get_watchdog_enable_status)(char *buf, size_t count);
+ int (*set_watchdog_enable_status)(int value);
+};
+
+extern int s3ip_sysfs_watchdog_drivers_register(struct s3ip_sysfs_watchdog_drivers_s *drv);
+extern void s3ip_sysfs_watchdog_drivers_unregister(void);
+
+```
+
+Sample code exposes watchdog register to sysfs, This code should be implemented by the vendor
+
+```
+#define WDT_INFO(fmt, args...) LOG_INFO("watchdog: ", fmt, ##args)
+...
+/*
+ * demo_set_watchdog_enable_status - Used to set watchdog enable status,
+ * @value: enable status value, 0: disable, 1: enable
+ *
+ * This function returns 0 on success,
+ * otherwise it returns a negative value on failed.
+ */
+static int demo_set_watchdog_enable_status(int value)
+{
+ /* add vendor codes here */
+ return -ENOSYS;
+}
+
+static struct s3ip_sysfs_watchdog_drivers_s drivers = {
+ /*
+ * set ODM watchdog sensor drivers to /sys/s3ip/watchdog,
+ * if not support the function, set corresponding hook to NULL.
+ */
+ .get_watchdog_identify = demo_get_watchdog_identify,
+ .get_watchdog_state = demo_get_watchdog_state,
+ .get_watchdog_timeleft = demo_get_watchdog_timeleft,
+ .get_watchdog_timeout = demo_get_watchdog_timeout,
+ .set_watchdog_timeout = demo_set_watchdog_timeout,
+ .get_watchdog_enable_status = demo_get_watchdog_enable_status,
+ .set_watchdog_enable_status = demo_set_watchdog_enable_status,
+};
+
+static int __init watchdog_dev_drv_init(void)
+{
+ int ret;
+
+ WDT_INFO("watchdog_init...\n");
+
+ ret = s3ip_sysfs_watchdog_drivers_register(&drivers);
+ if (ret < 0) {
+ WDT_ERR("watchdog drivers register err, ret %d.\n", ret);
+ return ret;
+ }
+ WDT_INFO("watchdog create success.\n");
+ return 0;
+}
+
+static void __exit watchdog_dev_drv_exit(void)
+{
+ s3ip_sysfs_watchdog_drivers_unregister();
+ WDT_INFO("watchdog_exit success.\n");
+ return;
+}
+
+module_init(watchdog_dev_drv_init);
+module_exit(watchdog_dev_drv_exit);
+```
+
+##### 3.2.2 s3ip sysfs service
+Workflow of the S3ip sysfs service
+- Delete old data, such as the /sys_switch directory and subdirectories
+- Install kernel modules, including s3ip_sysfs.ko and other driver kernel modules
+- Parse the configuration file and create the /sys_switch directory
+
+The S3ip sysfs service (aka s3ip_sysfs.service) configuration file is designed to simplify the /sys_switch directory creation process.
+The configuration file contains the following metadata:
+- path: Indicates the specific path of /sys_switch
+- type: Indicates the type of the path
+ - string: fixed string type
+ - path: real path type
+- value: indicates the real path or fixed string
+
+Sample configuration file to make /sys_switch witch S3ip sysfs Service
+
+```
+{
+ "s3ip_syfs_paths": [
+ # The /sys_switch/fan/num path specify the number of fans on the platform. This configuration makes the path read-only and return "6" in string format.
+ {
+ "path": "/sys_switch/fan/num",
+ "type" : "string",
+ "value" : "6",
+ "description": "number of fan"
+ },
+ # The /sys_switch/syseeprom path specify the syseeprom information. This configuration makes the path linked to /sys/class/i2c_adapter/i2c-block/hwmon/hwmon1/eeprom2/2-0048, so we can reuse old driver sysfs path
+ {
+ "path":"/sys_switch/syseeprom",
+ "Type":"path",
+ "Value":"/sys/class/i2c_adapter/i2c-block/hwmon/hwmon1/eeprom2/2-0048"
+ },
+ # the /sys_switch/fan give you all fan infomations. This configuration makes the path linked to /sys/s3ip/fan, so we can use driver base on the s3ip sysfs kernel module framework
+ {
+ "path":"/sys_switch/fan ",
+ "Type":"path",
+ "value":"/sys/s3ip/fan"
+ }
+ ]
+}
+```
+#### 3.3 Porting guide
+1. git clone sonic-buildimage to get the S3IP framework, the path framework is at sonic-buildimage/platform/s3ip-sysfs
+2. Verify the availability of the S3IP framework on the host computer
+ - Generate a host package, run the following command
+ - sonic-buildimage/platform/s3ip-sysfs/build.sh
+ - Install the package, run the following command
+ - dpkg -i s3ip-sysfs_1.0.0_amd64.deb
+ - Check the /sys_switch directory, run the following command
+ - tree -psv /sys_switch/
+3. Porting S3IP sysfs framework to platform project
+ - Create the S3IP sysfs service configuration file.
+ - Modify sonic-buildimage/platform/s3ip-sysfs/scripts/s3ip_sysfs_conf.json to create a configuration file
+ - This file should be installed to /etc/s3ip/s3ip_sysfs_conf.json on the device
+ - Implement the platform hardware driver, and export parameters through s3ip_sysfs.ko
+ - s3ip_sysfs. ko is generated by compiling sonic-buildimage/platform/s3ip-sysfs/s3ip_sysfs_frame source code
+ - Install the s3ip-sysfs.service on the device
+ - Copy service file sonic-buildimage/platform/s3ip-sysfs/scripts/s3ip-sysfs.service to the project.
+ - The service file needs to be installed in /etc/systemd/system/s3ip-sysfs.service on the device.
+ - When the platform package is installed, the vendor should enable s3ip-sysfs.service and start this service automatically when the device reboot
+ - After the platform package is uninstalled, the vendor should disable the s3ip-sysfs.service and remove the service file
+4. Self-test after integration
+ - Ensure that the /sys_switch directory conforms to the S3IP sysfs specification
+ - Hardware property information can be read and written normally
+
+### 4 Compare with [PDDF](https://github.com/sonic-net/SONiC/blob/master/doc/platform/brcm_pdk_pddf.md)
+
+The S3IP sysfs specification is intended to provide a more general set of hardware access interfaces. Using sysfs is definitely the best option, as it fits into the Linux design philosophy of everything being a file, and there are more tools and languages to deal with it.
+
+For traditional driver engineers, The S3IP SYSFS interface is very friendly and easy to debug, they only need to care about the content and format of the sysfs node. So the learning cost is zero and it's easy to understand and implement.
+
+For ODM vendors new to SONIC, opt for PDDF because you can do platform adaptation with a configuration file, which is cool and popular.
+
+S3IP SYSFS and PDDF both share similar goals of reducing vendor adaptation effort and increasing the reusability of device management software.
+
+However, there are many differences between the two frameworks, which are listed below. ODM vendors can choose the framework based on actual requirements.
+
+| Item | S3IP sysfs|PDDF|
+|-|-|-|
+|Requirements| The requirements are put forward from the user's perspective, and the sysfs node is summarized from the actual operation experience. The goal is to unify the interface for device management | The requirements are proposed from technical point of view aimed at platform driver and APIs development in SONiC. Only those SysFS which are required by SONiC platform APIs are exposed.
+|Ecosystem | Devices compliant with S3IP SYSFS specification have been widely used in data centers. The [S3IP](http://www.s3ip.org/) project involved both vendors and users[S3IP] (including Tencent, Alibaba, Baidu, Kuaishou, Meituan, Jingdong and more than a dozen ODM vendors). Vendors and users complete a closed-loop of requirements, standards and debugging tools that have the ability to iterate continuously. | PDDF is a new framework and it is developed in the SONiC context. Some ODM platforms are already using PDDF. PDDF is an underlying framework which ODMs can use for faster development but it does not exposes any fixed SysFS nodes to the user.
+|Development Mode | Regular development model, Programming is required to implement the requirements. ODM venders need to provide professional driver support for customers，Customers validating device with sysfs| ODM vendors can use common PDDF kernel drivers and user space common platform APIs. Only some platform specific device data needs to be provided by the ODMs in the form of JSON files. Validation is via usual SONiC CLIs.
+|Flexible | 1.Bus independent, The hardware support: Fan PSU System EEPROM Transceivers CPLD FPGA System LED Temperature sensors Current sensors Voltage sensors Slot Watchdog
2.Support scenarios with many customization requirements, such as FPGA-Polling, BMC management hardware and firmware upgrades
3.Normalized SYSFS is easy for hardware fault identification and prediction
4.Easy to debug for ODM users, and they need not care about the bus topology |PDDF can be used on the platforms which use I2C bus to communicate with the peripheral devices. Platforms which use BMC can also be brought up using PDDF. In future PDDF would be supported on platform using PCIE FPGA devices.
+|code position | https://github.com/sonic-net/sonic-buildimage/tree/master/platform/s3ip-sysfs| https://github.com/sonic-net/sonic-buildimage/tree/master/platform/pddf
+
+PDDF is not incompatible with S3IP SYSFS, we will combine the two parts into two Phases:
+
+Phase 1: The S3IP SYSFS Framework is integrated into the SONiC community so that Chinese ODM vendors can more easily contribute their existing platforms to the community, and other vendors can also have the opportunity to adapt their platforms according to S3IP specifications and expand their business opportunities in China. This is good for SONiC community ecosystem;
+
+Phase 2: PDDF and the S3IP SYSFS Framework will be integrated and presented as a framework, which makes more sense. Consumers decide whether to comply with the S3IP SYSFS specification by customizing the options provided by the framework.
+
+### SAI API
+N/A
+### Configuration and management
+N/A
+#### Manifest (if the feature is an Application Extension)
+Paste a preliminary manifest in a JSON format.
+#### CLI/YANG model Enhancements
+N/A
+#### Config DB Enhancements
+N/A
+### Warmboot and Fastboot Design Impact
+N/A
+### Restrictions/Limitations
+
+### Testing Requirements/Design
+
+New test cases need to be added
+
+1. Verify that the read and write properties of the sysfs node are as expected
+
+2. Whether the value of the sysfs node is as expected
+
+#### Unit Test cases
+N/A
+#### System Test cases
+N/A
+### Open/Action items - if any
+N/A
+
+NOTE: All the sections and sub-sections given above are mandatory in the design document. Users can add additional sections/sub-sections if required.
\ No newline at end of file
diff --git a/doc/s3ip_sysfs/s3ip_sysfs_specification.md b/doc/s3ip_sysfs/s3ip_sysfs_specification.md
new file mode 100644
index 00000000000..a88ecb497c7
--- /dev/null
+++ b/doc/s3ip_sysfs/s3ip_sysfs_specification.md
@@ -0,0 +1,239 @@
+# S3IP sysfs specification #
+
+## Table of Content
+ * [1. LED enumeration value](#1-led-enumeration-value)
+ * [2. Temperature sensor sysfs](#2-temperature-sensor-sysfs)
+ * [3. Voltage sensor sysfs](#3-voltage-sensor-sysfs)
+ * [4. Current sensor sysfs ](#4-current-sensor-sysfs)
+ * [5. Syseeprom infomation sysfs ](#5-syseeprom-information-sysfs)
+ * [6. Fan information sysfs](#6-fan-information-sysfs)
+ * [7. PSU information sysfs](#7-psu-information-sysfs)
+ * [8. Transceiver information sysfs](#8-transceiver-information-sysfs)
+ * [9. System LED sysfs](#9-system-led-sysfs)
+ * [10. FPGA information sysfs](#10-fpga-information-sysfs)
+ * [11. CPLD information sysfs](#11-cpld-information-sysfs)
+ * [12. Watchdog information sysfs](#12-watchdog-information-sysfs)
+ * [13. Slot information sysfs](#13-slot-information-sysfs)
+
+
+### 1. LED enumeration values
+| Value | Description |
+|--------|---------------------------------------------------|
+| 0 | dark |
+| 1 | green |
+| 2 | yellow |
+| 3 | red |
+| 4 | blue |
+| 5 | green light flashing |
+| 6 | yellow light flashing |
+| 7 | red light flashing |
+| 8 | blue light flashing |
+
+### 2. Temperature sensor sysfs
+The sysfs path of the temperature sensor information must be /sys_switch/temp_sensor/
+
+*Table2-1 Temperature Sensor SYSFS property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+/sys_switch/temp_sensor/number| RO| int| Total number of temperature sensors
+/sys_switch/temp_sensor/temp[n]/alias| RO| string| Identify temperature point location
+/sys_switch/temp_sensor/temp[n]/type| RO| string| Temperature sensor model
+/sys_switch/temp_sensor/temp[n]/max| R/W| int| Alarm threshold, unit: millidegree Celsius
+/sys_switch/temp_sensor/temp[n]/min| R/W| int| Alarm recovery threshold, unit: millidegree Celsius
+/sys_switch/temp_sensor/temp[n]/value| RO| int| Current temperature, unit: millidegree Celsius
+
+### 3. Voltage sensor sysfs
+The sysfs path of the voltage sensor information must be /sys_switch/vol_sensor/
+
+*Table3-1 Voltage Sensor SYSFS property *
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+/sys_switch/vol_sensor/number|RO|int| Total number of voltage sensors
+/sys_switch/vol_sensor/vol[n]/alias|RO|string| Identifying the location of the voltage sensor
+/sys_switch/vol_sensor/vol[n]/type|RO|string| Model of the voltage sensor
+/sys_switch/vol_sensor/vol[n]/max|R/W|int| Alarm threshold, unit: mV
+/sys_switch/vol_sensor/vol[n]/min|R/W|int| Alarm recovery threshold, unit: mV
+/sys_switch/vol_sensor/vol[n]/range|RO|int| Voltage output error value, such as +-500mV
+/sys_switch/vol_sensor/vol[n]/nominal_value|RO|int| Nominal value of supply voltage, unit: mV
+/sys_switch/vol_sensor/vol[n]/value|RO|int| Voltage value, unit: mV
+
+### 4. Current sensor sysfs
+The sysfs path of the current sensor information must be /sys_switch/curr_sensor/
+
+*Table4-1 Current Sensor SYSFS property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+/sys_switch/curr_sensor/number|RO|int| Total number of current sensors
+/sys_switch/curr_sensor/curr[n]/alias|RO|string| Identifying the location of the current sensor
+/sys_switch/curr_sensor/curr[n]/type|RO|string| Current sensor model
+/sys_switch/curr_sensor/curr[n]/max|R/W|int| Alarm threshold, unit: mA
+/sys_switch/curr_sensor/curr[n]/min|R/W|int| Alarm recovery threshold, unit: mA
+/sys_switch/curr_sensor/curr[n]/value|RO|int| Current value, unit: mA
+
+### 5. Syseeprom information sysfs
+The sysfs path of the syseeprom information must be /sys_switch/syseeprom
+
+*Table5-1 Syseeprom info SYSFS property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+/sys_switch/syseeprom|RO|int|The file content conforms to the ONIE standard binary
+
+### 6. Fan information sysfs
+The sysfs path of the fan information must be /sys_switch/fan/
+
+*Table6-1 fan info sysfs property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/fan/number |RO| int| Total number of fans
+|/sys_switch/fan/fan[n]/model_name |RO| string| Fan name
+|/sys_switch/fan/fan[n]/serial_number |RO| string| Fan serial number
+|/sys_switch/fan/fan[n]/part_number |RO| string| Fan Part Number
+|/sys_switch/fan/fan[n]/hardware_version |RO| string| Fan hardware version number
+|/sys_switch/fan/fan[n]/motor_number |RO| int| Number of fan motors
+|/sys_switch/fan/fan[n]/direction |RO| enum| The duct types are defined as follows: 0: F2B, forward air duct 1: B2F, rear duct
+|/sys_switch/fan/fan[n]/ratio |R/W| int| Motor speed percentage, value range 0-100
+|/sys_switch/fan/fan[n]/motor[n]/speed |RO| int| Speed value,unit: RPM
+|/sys_switch/fan/fan[n]/motor[n]/speed_tolerance |RO| int| Fan Speed tolerance (error range) ,unit: RPM
+|/sys_switch/fan/fan[n]/motor[n]/speed_target |RO| int| Motor standard speed value, unit: RPM
+|/sys_switch/fan/fan[n]/motor[n]/speed_max |RO| int| Maximum motor speed,unit: RPM
+|/sys_switch/fan/fan[n]/motor[n]/speed_min |RO| int| Minimum motor speed,unit: RPM
+|/sys_switch/fan/fan[n]/status |RO| enum| Fan states are defined as follows: 0: not present 1: present and normal 2: present and abnormal
+|/sys_switch/fan/fan[n]/led_status |R/W| enum| The fan status lights are defined as follows: See the definition of enumeration value of LED status light for details
+
+### 7. PSU information sysfs
+The sysfs path of the PSU(Power Supply Unit) information must be /sys_switch/psu/
+
+*Table7-1 Power Information sysfs Property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/psu/number |RO| int| Total number of PSUs
+|/sys_switch/psu/psu[n]/model_name |RO| string | PSU name
+|/sys_switch/psu/psu[n]/hardware_version |RO| string | PSU hardware version number
+|/sys_switch/psu/psu[n]/serial_number |RO| string | PSU serial number
+|/sys_switch/psu/psu[n]/part_number |RO| string | PSU part number
+|/sys_switch/psu/psu[n]/type|RO| enum | PSU Type: 0: DC 1: AC
+|/sys_switch/psu/psu[n]/in_curr |RO| int | PSU input current, unit: mA
+|/sys_switch/psu/psu[n]/in_vol |RO| int | PSU input voltage, unit: mV
+|/sys_switch/psu/psu[n]/in_power |RO| int | PSU input power, compute it from in_curr * in_vol, unit: uW
+|/sys_switch/psu/psu[n]/out_max_power |RO| int |The maximum output power of the PSU, unit: uW
+|/sys_switch/psu/psu[n]/out_curr |RO| int | PSU output current, unit: mA
+|/sys_switch/psu/psu[n]/out_vol |RO| int | PSU output voltage, unit: mV
+|/sys_switch/psu/psu[n]/out_power |RO| int | PSU output power, compute it from out_curr * out_vol, unit: uW
+|/sys_switch/psu/psu[n]/num_temp_sensors |RO| int | Number of temperature sensors
+|/sys_switch/psu/psu[n]/temp[n] | R/W| | Refer to temperature sensor definition
+|/sys_switch/psu/psu[n]/num_power_sensors |RO| int | Number of power sensors, TBD
+|/sys_switch/psu/psu[n]/power_sensor[n] | R/W| | Refer to power sensor definition, TBD
+|/sys_switch/psu/psu[n]/present|RO| enum | State: 0: not present 1: Incumbent
+|/sys_switch/psu/psu[n]/out_status|RO| enum | Output status, via POWER_OK inside the power supply pin judgment 0: abnormal 1: normal
+|/sys_switch/psu/psu[n]/in_status|RO| enum | Input status, judged by AC_OK pin inside the power supply broken 0: abnormal 1: normal
+|/sys_switch/psu/psu[n]/fan_speed |RO| int | PSU fan speed, unit: RPM
+|/sys_switch/psu/psu[n]/fan_ratio | R/W| Int| PSU fan speed duty cycle
+|/sys_switch/psu/psu[n]/led_status|RO| enum | The PSU status lights are defined as follows: See the definition of enumeration value of LED status light for details
+
+### 8. Transceiver information sysfs
+The sysfs of the transceiver module information must be /sys_switch/transceiver/
+
+*Table8-1 Transceiver module information sysfs Property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/transceiver/power_on |R/W| enum | The power state of all ports on the system: 0: power off 1: power on
+|/sys_switch/transceiver/eth[n]/power_on |R/W| enum | The power state: 0: power off 1: power on
+|/sys_switch/transceiver/eth[n]/tx_fault|RO| enum |module sending channel exception (including laser/TXCDR) 0: normal 1: abnormal. This information is exported by eeprom (eg QSFP28 standard), the node may not support;Otherwise, the node must support (such as SFP28 standard)
+|/sys_switch/transceiver/eth[n]/tx_disable|R/W| enum | Optical signal state 0: Turn on the optical signal 1: Turn off the optical signal. This information is exported by eeprom (eg QSFP28 standard), the node may not support; Otherwise, the node must support (such as SFP28 standard)
+|/sys_switch/transceiver/eth[n]/present|RO| enum | Present state 0: absent, not in place 1: present and normal
+|/sys_switch/transceiver/eth[n]/rx_los|RO| enum | Rx loss state(no optical signal received) 0: normal 1: abnormal This information is exported by eeprom (eg QSFP28 standard), the node may not support;Otherwise, the node must support (such as SFP28 standard)
+|/sys_switch/transceiver/eth[n]/reset|R/W| enum | Reset pin 0: no reset 1: reset This information supports exporting (such as QSFP28 standard), the node must support it; otherwise, the section point may not be supported (such as SFP28 standard)
+|/sys_switch/transceiver/eth[n]/low_power_mode|RO| enum | Low power mode state 0: high power 1: low power mode This information supports exporting (such as QSFP28 standard), the node must support it otherwise, the section point may not be supported (such as SFP28 standard)
+|/sys_switch/transceiver/eth[n]/interrupt|RO| enum | Module interrupt flag, indicating whether there is an interrupt 0: No interrupt occurred 1: Interrupt occurs This information supports exporting (such as QSFP28 standard), the node must support it; otherwise, the section point may not be supported (such as SFP28 standard)
+|/sys_switch/transceiver/eth[n]/eeprom |R/W| binary| eeprom compliant with optical module standards
+
+### 9. System LED sysfs
+The sysfs path of the LED state must be /sys_switch/sysled/
+
+*Table9-1 system LED SYSFS property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/sysled/sys_led_status|R/W|enum|System LED status, refer to LED enumeration value table for details
+|/sys_switch/sysled/bmc_led_status|R/W|enum|BMC LED status, refer to LED enumeration value table for details
+|/sys_switch/sysled/fan_led_status|R/W|enum|FAN LED status, refer to LED enumeration value table for details
+|/sys_switch/sysled/psu_led_status|R/W|enum|PSU LED status, refer to LED enumeration value table for details
+|/sys_switch/sysled/id_led_status|R/W|enum|Location LED status, refer to LED enumeration value table for details
+
+### 10. FPGA information sysfs
+The sysfs path of the FPGA Information must be /sys_switch/fpga/
+
+*Table10-1 FPGA Information sysfs Property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/fpga/number |RO |int| Total number of FPGAs
+|/sys_switch/fpga/fpga[n]/alias |RO |string| FPGA alias, Identifying the location of the FPGA
+|/sys_switch/fpga/fpga[n]/type |RO |string| FPGA model
+|/sys_switch/fpga/fpga[n]/firmware_version |RO |string| FPGA firmware version number
+|/sys_switch/fpga/fpga[n]/board_version |RO |string| FPGA hardware version number
+|/sys_switch/fpga/fpga[n]/reg_test |R/W |int| Test register, test basic functions available
+
+### 11. CPLD information sysfs
+The sysfs path of the CPLD information must be /sys_switch/cpld/
+
+*Table11-1 CPLD information sysfs Property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/cpld/number |RO |int| Total number of CPLDs
+|/sys_switch/cpld/cpld[n]/alias |RO |string| CPLD alias, Identifying the location of the CPLD
+|/sys_switch/cpld/cpld[n]/type |RO |string| CPLD model
+|/sys_switch/cpld/cpld[n]/firmware_version |RO |string| CPLD firmware version number
+|/sys_switch/cpld/cpld[n]/board_version |RO |string|CPLD hardware version number
+|/sys_switch/cpld/cpld[n]/reg_test |R/W |int|Test register, test basic function available
+
+### 12. Watchdog information sysfs
+The sysfs path of the watchdog information must be /sys_switch/watchdog/
+
+*Table12-1 watchdog information sysfs property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/watchdog/identify |RO| string| Watchdog identification, eg iTCO_wdt
+|/sys_switch/watchdog/enable|R/W|enum| Watchdog Status: 0: inactive 1: active
+|/sys_switch/watchdog/reset |WO| int | Feed watchdog
+|/sys_switch/watchdog/timeleft |RO| int | Watchdog timeout remaining time, unit:seconds
+|/sys_switch/watchdog/timeout|R/W| int | Watchdog timeout, unit: seconds
+
+### 13. Slot information sysfs
+
+the sysfs path of slot information must be /sys_switch/slot/
+
+*Table13-1 Slot information sysfs property*
+
+|Sysfs path|Permissions|Data type|Description|
+|-|-|-|-|
+|/sys_switch/slot/number|RO| int | Total number of card slots
+|/sys_switch/slot/slot[n]/model_name |RO| string| Slot name
+|/sys_switch/slot/slot[n]/hardware_version |RO| string| Slot hardware version number
+|/sys_switch/slot/slot[n]/serial_number |RO| string| Slot serial number
+|/sys_switch/slot/slot[n]/part_number |RO| string| Slot part number
+|/sys_switch/slot/slot[n]/status |RO| string| Slot status 0: ABSENT, not in place 1: OK, present and normal 2: NOT OK, in place and abnormal
+|/sys_switch/slot/slot[n]/led_status |R/W| enum| Slot status light
+|/sys_switch/slot/slot[n]/num_temp_sensors |RO| int| Number of temperature sensors on sub card
+|/sys_switch/slot/slot[n]/temp_sensor[n] |R/W| | Refer to temperature sensor definition
+|/sys_switch/slot/slot[n]/num_vol_sensors |RO| int| Number of sub card voltage sensors
+|/sys_switch/slot/slot[n]/vol_sensor[n] |R/W| | Refer to voltage sensor definition
+|/sys_switch/slot/slot[n]/num_curr_sensors |RO| int| Number of sub card current sensors
+|/sys_switch/slot/slot[n]/curr_sensor[n] |R/W| | Refer to current sensor definition
+|/sys_switch/slot/slot[n]/num_fpgas |RO| int| Number of sub card FPGAs
+|/sys_switch/slot/slot[n]/fpga[n] |R/W|| Refer to FPGA Information Sysfs Definition
+|/sys_switch/slot/slot[n]/num_cplds |RO| int| Number of sub card CPLDs
+|/sys_switch/slot/slot[n]/cpld[n] |R/W| | Refer to CPLD information Sysfs definition
+
+### 14. Power sensor sysfs
+The sysfs path of the power sensor information must be /sys_switch/power_sensor/
+Note: TBD. This section will be defined in the next stage. Most on-board DC-DC converters (also called PWM or pulse-width modulator chips) provide voltage, current and calculated power. They often provide power In and Power out, allowing easy measurement of efficiency. It is more reliable to read this directly rather than compute it from current * voltage, which might obtain readings at different times and result in invalid computation. It could also be more accurate because multiplying current * power in the controller results in compound loss of precision(rounded value * rounded value)
diff --git a/images/platform/s3ip_pddf.jpg b/images/platform/s3ip_pddf.jpg
new file mode 100644
index 00000000000..7820b11a9b6
Binary files /dev/null and b/images/platform/s3ip_pddf.jpg differ
diff --git a/images/s3ip_sysfs/s3ip_sysfs_demo.png b/images/s3ip_sysfs/s3ip_sysfs_demo.png
new file mode 100644
index 00000000000..7ca51ce2c23
Binary files /dev/null and b/images/s3ip_sysfs/s3ip_sysfs_demo.png differ
diff --git a/images/s3ip_sysfs/s3ip_sysfs_framework_scenario.svg b/images/s3ip_sysfs/s3ip_sysfs_framework_scenario.svg
new file mode 100644
index 00000000000..71562fe8f22
--- /dev/null
+++ b/images/s3ip_sysfs/s3ip_sysfs_framework_scenario.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/images/s3ip_sysfs/s3ip_sysfs_get_info_flow.svg b/images/s3ip_sysfs/s3ip_sysfs_get_info_flow.svg
new file mode 100644
index 00000000000..c95e22cb95d
--- /dev/null
+++ b/images/s3ip_sysfs/s3ip_sysfs_get_info_flow.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/images/s3ip_sysfs/s3ip_sysfs_scenario.svg b/images/s3ip_sysfs/s3ip_sysfs_scenario.svg
new file mode 100644
index 00000000000..4dafc26399a
--- /dev/null
+++ b/images/s3ip_sysfs/s3ip_sysfs_scenario.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/images/s3ip_sysfs/s3ip_sysfs_setup_flow.svg b/images/s3ip_sysfs/s3ip_sysfs_setup_flow.svg
new file mode 100644
index 00000000000..bf69c6672d5
--- /dev/null
+++ b/images/s3ip_sysfs/s3ip_sysfs_setup_flow.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file