Fix spelling in Platform PDDF doc (#2136)

- Fix grammar: that's -> that

Author: lihuay

doc/platform/brcm_pdk_pddf.md

@@ -725,7 +725,7 @@ fan<idx>_fault
 where idx represents the Fan index [1..32]
 ```
 
-Since PDDF has been changed to support platform 2.0 APIs, general design considers all the FANs inside a fantray as seperate FANs. If a fantray consist of two fans, front and rear, JSON object for FAN not only provides the access details for the front fan but also for the rear fan.
+Since PDDF has been changed to support platform 2.0 APIs, general design considers all the FANs inside a fantray as separate FANs. If a fantray consist of two fans, front and rear, JSON object for FAN not only provides the access details for the front fan but also for the rear fan.
 
 ##### 3.4.4.2 FAN JSON Design
 FAN JSON is structured to include the access-data for all the supported SysFS attributes.
@@ -1108,7 +1108,7 @@ The SysFS paths should be given as per the PDDF I2C topology description and the
 FPGA can be programmed as a I2C master controller. Some platforms use a FPGAPCIe card to control I2C devices and  the communication with the CPU is by PCIe interface. PDDF supports a FPGAPCIe card by providing the following modules:
 
 * FPGAPCIe Data Module:
-    - Mange access data defined in JSON via SysFS interface
+    - Manage access data defined in JSON via SysFS interface
     - Populate data and trigger FPGAPCIe instantiation
 * FPGAPCIe Driver Module:
     - PCIe device instantiation
@@ -1122,7 +1122,7 @@ connected FPGA, vendors need to provide the FPGA driver.
 
 ##### 3.4.12.1 FPGAPCIe JSON Design
 
-FPGAPCIe JSON object follows PDDF I2C topology JSON object design concept. FPGAPCIE object is under i2c keyword becuase it is programmed as I2c buses to control I2C client devices.
+FPGAPCIe JSON object follows PDDF I2C topology JSON object design concept. FPGAPCIE object is under i2c keyword because it is programmed as I2c buses to control I2C client devices.
 
 
 ```
@@ -1616,7 +1616,7 @@ If this field exists, the device name is displayed using this field. Otherwise,
 ipmitool and ipmiapi are two methods of getting ipmi data. ipmitool uses ipmitool command to get data from BMC while ipmiapi will use kernel ipmi interfaces to retrieve the data. ipmiapi will be implemented in the future.
 
 > **attr_name**:
-The PDDF BMC JSON design has the pre-defined list of the attribute names which is platform independent. IPMI is an standardized interface specification, but the naming convention of ipmitool output is vendor specific. The pre-defined attribue name list provides the ability to use generic PDDF generic platform APIs to retrieve information for all platforms.
+The PDDF BMC JSON design has the pre-defined list of the attribute names which is platform independent. IPMI is an standardized interface specification, but the naming convention of ipmitool output is vendor specific. The pre-defined attribute name list provides the ability to use generic PDDF generic platform APIs to retrieve information for all platforms.
 
 > **bmc_cmd**:
 There are two types of cmds: raw ipmi request and non raw ipmi request. The list of available ipmitool commands can be found by
@@ -1857,7 +1857,7 @@ Example,
 
 
 #### 3.7.3 LED Class
-There is no generic LED API class defined in PDDF. LED APIs related to a component has been made part of thats component's platform API class. System LED APIs are made part of PddfChassis class.
+There is no generic LED API class defined in PDDF. LED APIs related to a component has been made part of that component's platform API class. System LED APIs are made part of PddfChassis class.
 ```
 class PddfChassis(ChassisBase):
     def set_system_led(self, device_name, color):
@@ -2134,7 +2134,7 @@ root@sonic:/home/admin#
 
 
 
-> NOTE: Above output differs from the ouput in PDDF v1.0. This is because of the fact that FAN numbering scheme changed due to introduction of 2.0 platform APIs. Rear fans are now considered separate fans. In above output,
+> NOTE: Above output differs from the output in PDDF v1.0. This is because of the fact that FAN numbering scheme changed due to introduction of 2.0 platform APIs. Rear fans are now considered separate fans. In above output,
 > Fantray1_1: Front fan of frantray1
 > Fantray1_2: Rear fan of fantray1
 
@@ -2321,19 +2321,19 @@ S3IP sysfs specification defines a unified interface to access peripheral hardwa
 
 - 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
+- If any attribute which cannot be read should have a value of 'NA' i.e. tools should not fail due to non existence 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.
+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 specifications. 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.
+ - Platform Info Attributes: This includes the fixed information pertaining to the platform in entirety 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.
 
@@ -2355,7 +2355,7 @@ PDDF implements common kernel drivers for various components. These common drive
      |-|-|-|-|
      |/sys_switch/fan/fan[n]/status |RO| enum| Fan states are defined as follows:<br>0: not present<br>1: present and normal<br>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'.
+     - This is a combination of 'presence' and 'running_status' information 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
 
@@ -2394,11 +2394,11 @@ If the S3IP sysfs is required on a PDDF platform, it can be represented using th
 ...
 ```
 
-This pddf-s3ip service would create the sysfs as per the standards. It will also take care of linking the appropriate PDDF sysfs with the corrosponding S3IP sysfs.
+This pddf-s3ip service would create the sysfs as per the standards. It will also take care of linking the appropriate PDDF sysfs with the corresponding S3IP sysfs.
 
 In case the platform does not support some attributes present in the S3IP spec, 'NA' will be written to the attribute file so that the application does not fail.
 
-Once this is done, users can run their S3IP compliant applicaitons and test scripts on the platform.
+Once this is done, users can run their S3IP compliant applications and test scripts on the platform.
 
 #### 7.2.3 Adding S3IP Support for a Platform