!3249 同步英文到3.1release分支【不需要翻译】

Merge pull request !3249 from duangavin123/OpenHarmony-3.1-Release

en/device-dev/device-dev-guide.md

@@ -40,7 +40,7 @@ In addition, OpenHarmony provides a series of optional system components that ca
 | Basic&nbsp;capabilities | Using&nbsp;basic&nbsp;capabilities&nbsp;of<br/>&nbsp;OpenHarmony | -&nbsp;[Kernel&nbsp;for&nbsp;Mini&nbsp;Systems](kernel/kernel-mini-overview.md)<br/>-&nbsp;[Kernel&nbsp;for&nbsp;Small&nbsp;Systems](kernel/kernel-small-overview.md)<br/>-&nbsp;[Drivers](driver/driver-hdf-overview.md)<br/>-&nbsp;[Subsystems](subsystems/subsys-build-mini-lite.md)<br/>-&nbsp;[Security&nbsp;Guidelines](security/security-guidelines-overall.md)<br/>-&nbsp;[Privacy&nbsp;Protection](security/security-privacy-protection.md) |
 | Advanced&nbsp;development | Developing&nbsp;smart&nbsp;devices&nbsp;based<br/>&nbsp;on&nbsp;system&nbsp;capabilities | -&nbsp;[WLAN-connected&nbsp;Products](guide/device-wlan-led-control.md)<br/>-&nbsp;[Cameras&nbsp;Without&nbsp;a&nbsp;Screen](guide/device-iotcamera-control-overview.md)<br/>-&nbsp;[Cameras&nbsp;with&nbsp;a&nbsp;Screen](guide/device-camera-control-overview.md) |
 | Porting&nbsp;and&nbsp;adaptation | -&nbsp;Porting&nbsp;and&nbsp;adapting&nbsp;the&nbsp;<br/>OpenHarmony&nbsp;to&nbsp;an&nbsp;SoC<br/>-&nbsp;Porting&nbsp;and&nbsp;adapting&nbsp;the<br/>&nbsp;OpenHarmony&nbsp;to&nbsp;a<br/>&nbsp;third-party&nbsp;library | -&nbsp;[Mini&nbsp;System&nbsp;SoC&nbsp;Porting&nbsp;Guide](porting/oem_transplant_chip_prepare_knows.md)<br/>-&nbsp;[Small&nbsp;System&nbsp;SoC&nbsp;Porting&nbsp;Guide](porting/porting-smallchip-prepare-needs.md)<br/>-&nbsp;[Third-Party&nbsp;Library&nbsp;Porting&nbsp;Guide&nbsp;for&nbsp;Mini&nbsp;and&nbsp;Small&nbsp;Systems](porting/porting-thirdparty-overview.md) |
-| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](bundles/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](bundles/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](bundles/hpm-part-reference.md) |
+| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](hpm-part/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](hpm-part/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](hpm-part/hpm-part-reference.md) |
 | Reference | Referring&nbsp;to&nbsp;development&nbsp;specifications | [FAQs](faqs/faqs-overview.md) |
 
 
@@ -54,6 +54,6 @@ In addition, OpenHarmony provides a series of optional system components that ca
 | Basic&nbsp;capabilities | Using&nbsp;basic&nbsp;capabilities&nbsp;of&nbsp;OpenHarmony | -&nbsp;[Kernel&nbsp;for&nbsp;Standard&nbsp;Systems](kernel/kernel-standard-overview.md)<br/>-&nbsp;[Drivers](driver/driver-hdf-overview.md)<br/>-&nbsp;[Subsystems](subsystems/subsys-build-standard-large.md)<br/>-&nbsp;[Security&nbsp;Guidelines](security/security-guidelines-overall.md)<br/>-&nbsp;[Privacy&nbsp;Protection](security/security-privacy-protection.md) |
 | Advanced&nbsp;development | Developing&nbsp;smart&nbsp;devices<br/>&nbsp;based&nbsp;on&nbsp;system&nbsp;capabilities | -&nbsp;[Development&nbsp;Guidelines&nbsp;on&nbsp;Clock&nbsp;Apps](guide/device-clock-guide.md)<br/>-&nbsp;[Development&nbsp;Example&nbsp;for&nbsp;Platform&nbsp;Drivers](guide/device-driver-demo.md)<br/>-&nbsp;[Development&nbsp;Example&nbsp;for&nbsp;Peripheral&nbsp;Drivers](guide/device-outerdriver-demo.md) |
 | Porting&nbsp;and&nbsp;adaptation | Porting&nbsp;and&nbsp;adapting&nbsp;the<br/>&nbsp;OpenHarmony&nbsp;to&nbsp;a&nbsp;third-party&nbsp;library | -&nbsp;[Standard&nbsp;System&nbsp;Porting&nbsp;Guide](porting/standard-system-porting-guide.md)<br/>-&nbsp;[A&nbsp;Method&nbsp;for&nbsp;Rapidly&nbsp;Porting&nbsp;the&nbsp;OpenHarmony&nbsp;Linux&nbsp;Kernel](porting/porting-linux-kernel.md) |
-| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](bundles/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](bundles/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](bundles/hpm-part-reference.md) |
+| Contributing&nbsp;components | Contributing&nbsp;components<br/>&nbsp;to&nbsp;OpenHarmony | -&nbsp;[HPM Part Overview](hpm-part/hpm-part-about.md)<br/>-&nbsp;[HPM Part Development](hpm-part/hpm-part-development.md)<br/>-&nbsp;[HPM Part Reference](hpm-part/hpm-part-reference.md) |
 | Reference | Referring&nbsp;to&nbsp;development&nbsp;specifications | [FAQs](faqs/faqs-overview.md) 
 

en/device-dev/driver/Readme-EN.md

@@ -9,6 +9,7 @@
   - [HDF Development Example](driver-hdf-sample.md)
 - [Platform Driver Development](driver-develop.md)
   - [ADC](driver-platform-adc-develop.md)
+  - [DAC](driver-platform-dac-develop.md)
   - [GPIO](driver-platform-gpio-develop.md)
   - [HDMI](driver-platform-hdmi-develop.md)
   - [I2C](driver-platform-i2c-develop.md)
@@ -26,12 +27,14 @@
   - [Watchdog](driver-platform-watchdog-develop.md)
 - [Platform Driver Usage](driver-platform.md)
   - [ADC](driver-platform-adc-des.md)
+  - [DAC](driver-platform-dac-des.md)
   - [GPIO](driver-platform-gpio-des.md)
   - [HDMI](driver-platform-hdmi-des.md)
   - [I2C](driver-platform-i2c-des.md)
   - [I3C](driver-platform-i3c-des.md)
   - [MIPI CSI](driver-platform-mipicsi-des.md)
   - [MIPI DSI](driver-platform-mipidsi-des.md)
+  - [Pin](driver-platform-pin-des.md)
   - [PWM](driver-platform-pwm-des.md)
   - [Regulator](driver-platform-regulator-des.md)
   - [RTC](driver-platform-rtc-des.md)
@@ -47,3 +50,5 @@
   - [Audio](driver-peripherals-audio-des.md)
   - [USB](driver-peripherals-usb-des.md)
   - [Camera](driver-peripherals-camera-des.md)
+  - [Vibrator](driver-peripherals-vibrator-des.md)
+  - [Light](driver-peripherals-light-des.md)
\ No newline at end of file

en/device-dev/driver/driver-develop.md

@@ -2,6 +2,8 @@
 
 -   **[ADC](driver-platform-adc-develop.md)**  
 
+-   **[DAC](driver-platform-dac-develop.md)**  
+
 -   **[GPIO](driver-platform-gpio-develop.md)**  
 
 -   **[HDMI](driver-platform-hdmi-develop.md)**

en/device-dev/driver/driver-hdf-development.md

-# Driver Development<a name="EN-US_TOPIC_0000001051930361"></a>
+# Driver Development
 
-## Driver Model<a name="section157425168112"></a>
 
-The HDF is designed based on the component-based driver model. This model allows refined driver management and normalizes driver development and deployment. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes.  [Figure 1](#fig3580184214210)  shows the HDF driver model.
+## Driver Model
 
-**Figure  1**  HDF driver model<a name="fig3580184214210"></a>  
-![](figures/hdf-driver-model.png "hdf-driver-model")
+The Hardware Driver Foundation (HDF) is designed based on the component-based driver model. This model allows refined driver management and standardize driver development and deployment. Device drivers of the same type are placed in the same host. You can develop and deploy the drivers separately. One driver can have multiple nodes. The figure below shows the HDF driver model.
 
-## How to Develop<a name="section1969312275533"></a>
+  **Figure 1** HDF driver model
 
-Driver development based on the HDF involves driver implementation and driver configuration. The development procedure is as follows:
+  ![](figures/hdf-driver-model.png)
 
-1.  <a name="li35182436435"></a>Implement a driver.
 
+## How to Development
+
+The HDF-based driver development involves driver implementation and driver configuration. The development procedure is as follows:
+
+1. Implement a driver.
    To implement a driver, compile driver service code and register a driver entry.
 
    - Driver service code
@@ -23,7 +25,7 @@ Driver development based on the HDF involves driver implementation and driver co
       
       #define HDF_LOG_TAG "sample_driver"   // Tag contained in logs. If no tag is not specified, the default HDF_TAG is used.
       
-        // The driver service interface must be bound to the HDF for you to use the service capability.
+      // Service capabilities provided by the driver. Bind the service APIs to the HDF.
       int32_t HdfSampleDriverBind(struct HdfDeviceObject *deviceObject)
       {
           HDF_LOGD("Sample driver bind success");
@@ -44,11 +46,10 @@ Driver development based on the HDF involves driver implementation and driver co
           return;
       }
       ```
-
    - Registering the driver entry with the HDF
      
       ```
-        // Define the object of the driver entry. The object must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h).
+      // Define a driver entry object. It must be a global variable of the HdfDriverEntry type (defined in hdf_device_desc.h). 
       struct HdfDriverEntry g_sampleDriverEntry = {
           .moduleVersion = 1,
           .moduleName = "sample_driver",
@@ -57,20 +58,18 @@ Driver development based on the HDF involves driver implementation and driver co
           .Release = HdfSampleDriverRelease,
       };
       
-        // Call HDF_INIT to register the driver entry with the HDF framework. When loading the driver, call the Bind function and then the Init function. If the Init function fails to be called, the HDF will call Release to release the driver resource and exit.
+      // Call HDF_INIT to register the driver entry with the HDF. When loading the driver, the HDF calls the Bind() function first and then the Init() function. If the Init() function fails to be called, the HDF will call Release() to release the driver resources and exit the driver model. 
       HDF_INIT(g_sampleDriverEntry);
       ```
 
 2. Build the driver.
-
    - LiteOS
+      Modify **makefile** and **BUILD.gn**.
 
-     Modify **makefile** and **BUILD.gn**:
-
-     * makefile:
-
+      - makefile:
          Use the **makefile** template provided by the HDF to compile the driver code.
 
+         
          ```
          include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk # Import the content predefined by the HDF. This operation is mandatory.
          MODULE_NAME :=    # File to be generated.
@@ -82,15 +81,16 @@ Driver development based on the HDF involves driver implementation and driver co
 
          Add the path of the generated file to **hdf_lite.mk** in the **drivers/adapter/khdf/liteos** directory to link the file to the kernel image. The following is an example:
 
+         
          ```
          LITEOS_BASELIB += -lxxx # Static library generated by the link.
          LIB_SUBDIRS    +=         # Directory in which the driver code makefile is located.
          ```
 
-     * BUILD.gn:
-
+      - **BUILD.gn**:
          Add **BUILD.gn**. The content of **BUILD.gn** is as follows:
 
+         
          ```
          import("//build/lite/config/component/lite_component.gni")
          import("//drivers/adapter/khdf/liteos/hdf.gni")
@@ -111,6 +111,7 @@ Driver development based on the HDF involves driver implementation and driver co
 
          Add the directory where the **BUILD.gn** file of the driver is located to **/drivers/adapter/khdf/liteos/BUILD.gn**.
 
+         
          ```
          group("liteos") {
                 public_deps = [ ":$module_name" ]
@@ -119,44 +120,47 @@ Driver development based on the HDF involves driver implementation and driver co
                    ]
          }
          ```
-
    - Linux
-
       To define the driver control macro, add the **Kconfig** file to the driver directory **xxx** and add the path of the **Kconfig** file to **drivers/adapter/khdf/linux/Kconfig**.
 
+      
       ```
       source "drivers/hdf/khdf/xxx/Kconfig" # Kernel directory to which the HDF module is soft linked.
       ```
 
       Add the driver directory to **drivers/adapter/khdf/linux/Makefile**.
 
+      
       ```
       obj-$(CONFIG_DRIVERS_HDF)  += xxx/
       ```
 
       Add a **Makefile** to the driver directory **xxx** and add code compiling rules of the driver to the **Makefile** file.
 
+      
       ```
       obj-y  += xxx.o
       ```
 
 3. Configure the driver.
+   HDF Configuration Source (HCS) is the source code that describes the configuration of the HDF. For details about the HCS, see [Driver Configuration Management](../driver/driver-hdf-manage.md).
 
-    HDF Configuration Source (HCS) is the source code that describes the configuration of the HDF. For details about the HCS, see [Driver Configuration Management](driver-hdf-manage.md).
-
-    The driver configuration consists of the driver device description defined by the HDF and private driver configuration information.
+   The driver configuration consists of the driver device description defined by the HDF and the private driver configuration.
 
    - (Mandatory) Driver device description
+      The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device_info.hcs** defined by the HDF for drivers developed based on the HDF. The following is an example:
 
-        The information required for the HDF to load drivers comes from the driver device description defined by the HDF. Therefore, the device description must be added to the configuration file **device_info.hcs** defined by the HDF for drivers developed based on the HDF.The following is an example:
       
       ```
       root {
           device_info {
               match_attr = "hdf_manager";
-                template host {       // Host template. If the node (for example, sample_host) that inherits the template uses default values in the template, the values of the node fields can be omitted.
+              template host {       // Host template. If the node (for example, sample_host) uses the default values in the template, the values of the node fields can be omitted.
                   hostName = "";
                   priority = 100;
+                  uid = "";        // User ID (UID) of the user-mode process. By default, it is left empty, that is, set to the value defined for hostName, which indicates a common user.
+                  gid = "";        // Group ID (GID) of the user-mode process. By default, it is left empty, that is, set to the value defined for hostName, which indicates a common user group.
+                  caps = [""]];     // Linux capabilities of the user-mode process. It is left empty by default. Set this parameter based on service requirements.
                   template device {
                       template deviceNode {
                           policy = 0;
@@ -170,27 +174,37 @@ Driver development based on the HDF involves driver implementation and driver co
                   }
               }
               sample_host :: host{
-                    hostName = "host0";    // Host name. The host node is used to store a certain type of drivers.
+                  hostName = "host0";    // Host name. The host node is used to store a type of drivers.
                   priority = 100;        // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random.
-                    device_sample :: device {        // Device node of sample
-                        device0 :: deviceNode {      // DeviceNode of the sample driver
-                            policy = 1;              // Driver service release policy. For details, see section Driver Service Management.
-                            priority = 100;          // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random.
+                  caps = ["DAC_OVERRIDE", "DAC_READ_SEARCH"];   // Linux capabilities of the user-mode process.
+                  device_sample :: device {        // Sample device node.
+                      device0 :: deviceNode {      // DeviceNode of the sample driver.
+                          policy = 1;             // Driver service release policy. For details, see the Driver Service Management.
+                          priority = 100;          // Driver startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random.
                           preload = 0;            // On-demand loading of the driver. For details, see "NOTE" at the end of this section.
-                            permission = 0664;       // Permission for the driver to create device nodes.
-                            moduleName = "sample_driver";   // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure.
-                            serviceName = "sample_service";    // Name of the service released by the driver. The name must be unique.
-                            deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
+                          permission = 0664;       // Permission for the driver to create a device node.
+                          moduleName = "sample_driver"; // Driver name. The value of this field must be the same as that of moduleName in the HdfDriverEntry structure.
+                          serviceName = "sample_service";    // Name of the service published by the driver. The service name must be unique.
+                          deviceMatchAttr = "sample_config"; // Keyword for matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver.
                       }
                   }
               }
           }
       }
       ```
+     > ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**<br/>
 
-    -   \(Optional\) Private configuration information of the driver
+     -  **uid**, **gid**, and **caps** are startup configuration for user-mode drivers and do not need to be configured for kernel-mode drivers.
+      - According to the principle of least privilege for processes, **uid** and **gid** do not need to be configured for service modules. In the preceding example, **uid** and **gid** are left empty (granted with the common user rights) for sample_host.
+     - If you need to set **uid** and **gid** to **system** or **root** due to service requirements, contact security experts for review.
+      - The process UID is configured in **base/startup/init_lite/services/etc/passwd**, and the process GID is configured in **base/startup/init_lite/services/etc/group**. For details, see [Adding a System Service User Group]( https://gitee.com/openharmony/startup_init_lite/wikis).
+     -  If CAP_DAC_OVERRIDE needs to be configured for a service module, set **caps = ["DAC_OVERRIDE"]** instead of **caps = ["CAP_DAC_OVERRIDE"]**.
+
+      
+
+   - (Optional) Private configuration information of the driver
+      If the driver has private configuration, you can add a driver configuration file to set default driver configuration. When loading the driver, the HDF obtains and saves the corresponding configuration in **property** of **HdfDeviceObject**, and passes the configuration to the driver through **Bind()** and **Init()** (see step 1). The following is an example of the driver configuration:
    
-        If the driver has private configurations, you can add a driver configuration file to fill in the default configuration information of the driver. When loading the driver, the HDF obtains the information and saves it in the  **property**  of  **HdfDeviceObject**, and transfers it to the driver using  **Bind**  and  **Init**  \(see  [1](#li35182436435)\). The following is an example of the driver configuration information:
       
       ```
       root {
@@ -202,7 +216,8 @@ Driver development based on the HDF involves driver implementation and driver co
       }
       ```
    
-        After the configuration information is defined, you need to add the configuration file to the board-level configuration entry file  **hdf.hcs**. \(You can use the DevEco to perform on-click configuration. For details, see the description about the driver development suite.\) The following is an example:
+      After the configuration, add the configuration file to the board-level configuration entry file **hdf.hcs**. (You can use DevEco to perform on-click configuration. For details, see the description about the driver development suite.) The following is an example:
+
       
       ```
       #include "device_info/device_info.hcs"
@@ -210,10 +225,11 @@ Driver development based on the HDF involves driver implementation and driver co
       ```
 
 
-
->![](../public_sys-resources/icon-note.gif) **NOTE:** 
->On-demand loading and sequential loading are supported. The detailed usage is as follows:
->-   On-demand loading
+> ![icon-note.gif](../public_sys-resources/icon-note.gif) **NOTE**<br/>
+> Drivers can be loaded on demand or in sequence.
+>
+> - On-demand loading
+>
 >   ```
 >   typedef enum {
 >       DEVICE_PRELOAD_ENABLE = 0,
@@ -222,6 +238,12 @@ Driver development based on the HDF involves driver implementation and driver co
 >       DEVICE_PRELOAD_INVALID
 >   } DevicePreload;
 >   ```
->    If the **preload** field in the configuration file is set to **0** (DEVICE\_PRELOAD\_ENABLE), the driver is loaded by default during the system boot process. If **preload** is set to **1** (DEVICE\_PRELOAD\_ENABLE\_STEP2), the driver is loaded after a quick start is complete if the system supports quick start. If the system does not support quick start, the value **1** has the same meaning as DEVICE\_PRELOAD\_ENABLE. If **preload** is set to **2** (DEVICE\_PRELOAD\_DISABLE), the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service (for details, see [Driver Message Mechanism Management](driver-hdf-message-management.md)), the HDF attempts to dynamically load the driver if the driver service does not exist.
->-   Sequential loading \(drivers must be loaded by default\)
->    In the configuration file, the  **priority**  field \(the value is an integer ranging from 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority.
+>
+>   If **preload** in the configuration file is set to **0** (**DEVICE_PRELOAD_ENABLE**), the driver is loaded by default during the system boot process. 
+>
+>   If **preload** is set to **1** (**DEVICE\_PRELOAD\_ENABLE\_STEP2**), the driver is loaded after a quick start is complete if the system supports quick start. If the system does not support quick start, the value **1** has the same meaning as **DEVICE\_PRELOAD\_ENABLE**. 
+>
+>   If **preload** is set to **2** (**DEVICE\_PRELOAD\_DISABLE**), the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service (for details, see [Driver Message Mechanism Management](driver-hdf-message-management.md)), the HDF attempts to dynamically load the driver if the driver service does not exist.
+>
+> - Sequential loading (drivers must be loaded by default)
+>   In the configuration file, the **priority** field \(value range: 0 to 200\) indicates the priority of the host and driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority.

en/device-dev/driver/driver-peripherals-lcd-des.md

@@ -159,9 +159,9 @@ The following example shows code for developing an LCD driver:
 #define HORIZONTAL_BACK_PORCH     20
 #define HORIZONTAL_FRONT_PORCH    20
 #define HORIZONTAL_SYNC_WIDTH     10
-#define VERTIACL_BACK_PORCH       14
-#define VERTIACL_FRONT_PORCH      16
-#define VERTIACL_SYNC_WIDTH       2
+#define VERTICAL_BACK_PORCH       14
+#define VERTICAL_FRONT_PORCH      16
+#define VERTICAL_SYNC_WIDTH       2
 #define FRAME_RATE                60
 
 /* PanelInfo structure */
@@ -300,9 +300,9 @@ static struct PanelInfo g_panelInfo = {
     .hbp = HORIZONTAL_BACK_PORCH,       /* horizontal back porch */
     .hfp = HORIZONTAL_FRONT_PORCH,      /* horizontal front porch */
     .hsw = HORIZONTAL_SYNC_WIDTH,       /* horizontal sync width */
-    .vbp = VERTIACL_BACK_PORCH,         /* vertiacl back porch */
-    .vfp = VERTIACL_FRONT_PORCH,        /* vertiacl front porch */
-    .vsw = VERTIACL_SYNC_WIDTH,         /* vertiacl sync width */
+    .vbp = VERTICAL_BACK_PORCH,         /* vertical back porch */
+    .vfp = VERTICAL_FRONT_PORCH,        /* vertical front porch */
+    .vsw = VERTICAL_SYNC_WIDTH,         /* vertical sync width */
     .frameRate = FRAME_RATE,            /* frame rate */
     .intfType = MIPI_DSI,               /* panel interface type */
     .intfSync = OUTPUT_USER,            /* output timming type */

en/device-dev/driver/driver-peripherals-light-des.md

@@ -148,7 +148,7 @@ The light driver model provides APIs to obtain information about all the lights
          HdfWorkDestroy(&drvData->work);
          HdfWorkQueueDestroy(&drvData->workQueue);
          (void)OsalMutexDestroy(&drvData->mutex);
-         (void)OsalMemFree(drvData);
+         OsalMemFree(drvData);
          g_lightDrvData = NULL;
      }
      ```

en/device-dev/driver/driver-peripherals-sensor-des.md

@@ -8,6 +8,7 @@
 The sensor driver model masks the sensor hardware differences and provides interfaces for the upper-layer sensor service to implement basic sensor capabilities, including querying the sensor list, enabling or disabling a sensor, subscribing to or unsubscribing from sensor data changes, and setting sensor options. The model is developed on the Hardware Driver Foundation (HDF), Operating System Abstraction Layer (OSAL), and platform driver interfaces (such as the I2C, SPI, and UART buses). It provides functionalities such as cross-OS migration and differentiated device configurations. The figure below shows the architecture of the sensor driver model.
 
 **Figure 1** Sensor driver model
+ 
 ![Sensor driver model](figures/sensor_driver_model.png)
 
 ### Basic Concepts
@@ -44,12 +45,12 @@ The following uses the acceleration sensor driver on the Hi3516D V300 developmen
 ### When to Use
 
 - Data provided by the gravity and gyroscope sensors denotes the tilt and rotation of the device, which helps your application improve user experience in games.
-- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This can further reduce power consumption.
+- Data provided by the proximity sensor denotes the distance between the device and a visible object, which enables the device to automatically turn on or off its screen accordingly to prevent accidental touch on the screen. For example, when the proximity sensor detects the user face approaches the earpiece during a call, it triggers backlight of the screen to be turned off. This prevents the screen from being accidentally touched and further reduces power consumption.
 - Data provided by the barometric pressure sensor helps your application accurately determine the altitude of the device.
 - Data provided by the ambient light sensor helps your device automatically adjust its backlight.
 - Data provided by the Hall effect sensor implements the smart cover mode of your device. When the smart cover is closed, a small window is opened on the phone to reduce power consumption. 
 
-### Available APIs<a name="section188213414114"></a>
+### Available APIs
 
 The sensor driver model offers the following APIs:
 
@@ -61,7 +62,7 @@ The sensor driver model offers the following APIs:
 
 The sensor driver model provides APIs for the hardware service to make sensor service development easier. See the table below.
 
-**Table 1** APIs for the members in the PinCntlrMethod structure
+**Table 1** APIs of the sensor driver model
 
 | API| Description| 
 | ----- | -------- |
@@ -111,9 +112,9 @@ The sensor driver model also provides certain driver development APIs that need
 | void ReadSensorData(void) | Reads sensor data.|
 
 
-For details about the interface implementation, see [How to Develop](#section7893102915819).
+For details about the interface implementation, see "How to Develop" below.
 
-### How to Develop<a name="section7893102915819"></a>
+### How to Develop
 1. Develop the acceleration sensor abstract driver. Specifically, implement the **Bind**, **Init**, **Release**, and **Dispatch** functions.
 
    - Implement the entry function for the acceleration sensor.
@@ -513,12 +514,11 @@ For details about the interface implementation, see [How to Develop](#section789
 
 >![](../public_sys-resources/icon-note.gif) **NOTE**
 >
->- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see [Table 2](#table1156812588320).
->
->- You need to implement the following functions: certain sensor operation interfaces (listed in [Table 3](#table1083014911336)) and sensor chipset HCS configuration.
-> - You also need to verify basic driver functions.
+>- The sensor driver model provides certain APIs to implement sensor driver capabilities, including the driver device management, abstract bus and platform operation, common configuration, and configuration parsing capabilities. For details about them, see Table 2.
+>- You need to implement the following functions: certain sensor operation interfaces (listed in Table 3) and sensor chipset HCS configuration.
+>- You also need to verify basic driver functions.
 
-### Commissioning and Verifying<a name="section106021256121219"></a>
+### How to Verify
 
 After the driver is developed, you can develop self-test cases in the sensor unit test to verify the basic functions of the driver. Use the developer self-test platform as the test environment.
 
@@ -545,7 +545,7 @@ void HdfSensorTest::SetUpTestCase()
 {
     g_sensorDev = NewSensorInterfaceInstance();
     if (g_sensorDev == nullptr) {
-        printf("test sensorHdi get Module instace failed\n\r");
+        printf("test sensorHdi get Module instance failed\n\r");
     }
 }
 /* Release case resources. */

en/device-dev/driver/driver-platform-dac-des.md

+# DAC
+
+
+## Overview
+
+### DAC
+
+A digit-to-analog converter (DAC) is a device that converts a digital signal into an analog signal in electronics.
+
+The DAC APIs provide a set of methods for DAC data transfer, including:
+
+- Opening or closing a DAC device
+- Setting the target digital-to-analog (DA) value
+
+
+### Basic Concepts
+
+The DAC module provides the output channel for the process control computer system. It connects to the executor to implement automatic control of the production process. It is also an important module in the analog-to-digital converter using feedback technologies.
+
+- Resolution
+
+  The number of binary bits that can be converted by a DAC. A greater number of bits indicates a higher resolution.
+
+- Conversion precision
+
+  Difference between the actual output value of the DAC and the theoretical value when the maximum value is added to the input end. The conversion precision of a DAC converter varies depending on the structure of the chip integrated on the DAC and the interface circuit configuration. The ideal conversion precision value should be as small as possible. To achieve optimal DAC conversion precision, the DAC must have high resolution. In addition, errors in the devices or power supply of the interface circuits will affect the conversion precision. When the error exceeds a certain degree, a DAC conversion error will be caused.
+
+- Conversion speed
+
+  The conversion speed is determined by the setup time. The setup time is the period from the time the input suddenly changes from all 0s to all 1s to the time the output voltage remains within the FSR ± ½LSB (or FSR ± x%FSR). It is the maximum response time of the DAC, and hence used to measure the conversion speed.
+  
+  The full scale range (FSR) is the maximum range of the output signal amplitude of a DAC. Different DACs have different FSRs, which can be limited by positive and negative currents or voltages.
+  
+  The least significant byte (LSB) refers to bit 0 (the least significant bit) in a binary number.
+
+### Working Principles
+
+In the Hardware Driver Foundation (HDF), the DAC module uses the unified service mode for API adaptation. In this mode, a device service is used as the DAC manager to handle access requests from the devices of the same type in a unified manner. The unified service mode applies to the scenario where there are many device objects of the same type. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services. The figure below shows the unified service mode.
+
+The DAC module is divided into the following layers:
+- The interface layer provides APIs for opening or closing a device and writing data.
+- The core layer provides the capabilities of binding, initializing, and releasing devices.
+- The adaptation layer implements other functions.
+
+![](../public_sys-resources/icon-note.gif)NOTE<br/>The core layer can call the functions of the interface layer and uses the hook to call functions of the adaptation layer. In this way, the adaptation layer can indirectly call the functions of the interface layer, but the interface layer cannot call the functions of the adaptation layer.
+
+**Figure 1** Unified service mode
+
+![](figures/unified-service-mode.png "DAC-unified-service-mode")
+
+### Constraints
+
+ Currently, the DAC module supports only the kernels (LiteOS) of mini and small systems.
+
+## Development Guidelines
+
+### When to Use
+
+ The DAC module converts digital signals into analog signals in the form of current, voltage, or charge. It is mainly used in audio devices. Audio players and headsets use the DAC module as the digital-to-analog conversion channels.
+
+### Available APIs
+
+The table below describes the APIs of the DAC module. For more details, see API Reference.
+
+**Table 1** DAC driver APIs
+
+| API                                                     | Description        |
+| :------------------------------------------------------------| :------------ |
+| DevHandle DacOpen(uint32_t number)                           | Opens a DAC device. |
+| void DacClose(DevHandle handle)                              | Closes a DAC device. |
+| int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val) | Sets the target DA value. |
+
+### How to Develop
+
+The figure below illustrates the process of using a DAC device.
+
+**Figure 2** Process of using a DAC device
+ 
+![](figures/process-of-using-DAC.png "Process of using a DAC")
+
+#### Opening a DAC Device
+
+Call **DacOpen()** to open a DAC device before performing the DA conversion.
+
+```
+DevHandle DacOpen(uint32_t number);
+```
+
+**Table 2** Description of DacOpen
+
+| **Parameter**      | Description         |
+| ---------- | ----------------- |
+| number     | DAC device number.        |
+| **Return Value**| **Description**   |
+| NULL       | Failed to open the DAC device.  |
+| Device handle  | Handle of the DAC device opened.|
+
+
+
+Open device 1 of the two ADC devices (numbered 0 and 1) in the system.
+
+```
+DevHandle dacHandle = NULL; /* DAC device handle /
+
+/* Open the DAC device. */
+dacHandle = DacOpen(1);
+if (dacHandle == NULL) {
+    HDF_LOGE("DacOpen: failed\n");
+    return;
+}
+```
+
+#### Setting the Target DA Value
+
+```
+int32_t DacWrite(DevHandle handle, uint32_t channel, uint32_t val);
+```
+
+**Table 3** Description of DacWrite
+
+
+| **Parameter**      | Description      |
+| ---------- | -------------- |
+| handle     | DAC device handle.   |
+| channel    | DAC channel number. |
+| val        | DA value to set.    |
+| **Return Value**| **Description**|
+| 0          | The operation is successful.      |
+| Negative value      | The operation failed.      |
+
+```
+/* Write the target DA value through the DAC_CHANNEL_NUM channel. */
+    ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret);
+        DacClose(dacHandle);
+        return -1;
+    }
+```
+
+#### Closing a DAC Device
+
+After the DAC communication is complete, call **DacClose()** to close the DAC device.
+```
+void DacClose(DevHandle handle);
+```
+
+**Table 4** Description of DacClose
+
+
+| **Parameter**      | Description      |
+| ---------- | -------------- |
+| handle     | DAC device handle.   |
+| **Return Value**| **Description**|
+| void       | -            |
+
+
+
+Example:
+
+```
+DacClose(dacHandle); /* Close the DAC device. */
+```
+
+## Development Example
+
+The procedure is as follows:
+
+1. Open the DAC device based on the device number and obtain the device handle.
+2. Set the DA value. If the operation fails, close the device handle.
+3. Close the DAC device handle if the access to the DAC is complete.
+
+You can obtain the operation result by printing the log information based on the **val**.
+
+```
+#include "hdmi_if.h"          /* Header file for DAC APIs */
+#include "hdf_log.h"         /* Header file for log APIs */
+
+/* Define device 0, channel 1. */
+#define DAC_DEVICE_NUM 0
+#define DAC_CHANNEL_NUM 1
+
+/* Main entry of DAC routines. */
+static int32_t TestCaseDac(void)
+{
+    // Set the target DA value.
+    uint32_t val = 2;
+    int32_t ret;
+    DevHandle dacHandle;
+
+    /* Open the DAC device. */
+    dacHandle = DacOpen(DAC_DEVICE_NUM);
+    if (dacHandle == NULL) {
+        HDF_LOGE("%s: Open DAC%u fail!", __func__, DAC_DEVICE_NUM);
+        return -1;
+    }
+
+    /* Write data. */
+    ret = DacWrite(dacHandle, DAC_CHANNEL_NUM, val);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("%s: tp DAC write reg fail!:%d", __func__, ret);
+        DacClose(dacHandle);
+        return -1;
+    }
+
+    /* Close the DAC device. */
+    DacClose(dacHandle);
+
+    return 0;
+}
+```

en/device-dev/driver/driver-platform-i3c-des.md

@@ -225,7 +225,7 @@ if (ret != 2) {
 }
 ```
 
->![](./public_sys-resources/icon-caution.gif) **Caution**
+>![](../public_sys-resources/icon-caution.gif) **Caution**
 >
 >-   The device address in the **I3cMsg** structure does not contain the read/write flag bit. The read/write information is passed by the read/write control bit in the member variable **flags**.
 >-   The **I3cTransfer()** function does not limit the number of message structures or the length of data in each message structure. The I3C controller determines these two limits.

en/device-dev/driver/driver-platform-i3c-develop.md

@@ -164,7 +164,7 @@ The I3C module adaptation involves the following steps:
     
         ```c
         struct VirtualI3cCntlr {
-            struct AdcDevice device;// (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr.
+            struct I3cCntlr cntlr;   // (Mandatory) Control object at the core layer. For details, see the following description of I3cCntlr.
             volatile unsigned char *regBase;// (Mandatory) Register base address.
             uint32_t regBasePhy;     // (Mandatory) Physical base address of the register.
             uint32_t regSize;        // (Mandatory) Bit width of the register.

en/device-dev/driver/driver-platform-pin-des.md

+#  Pin
+
+
+## Overview<a name="section1"></a>
+
+### Pin<a name="section2"></a>
+
+-   The pin, also called pin controller, manages pin resources of system on a chip (SoC) vendors and provides the pin multiplexing function.
+-   The pin module defines a set of common methods for managing pins, including:
+    -   Obtaining or releasing the pin description handle: The kernel compares the pin name passed in with the pin names of each controller in the linked list. If a match is found, a pin description handle is obtained. After the operation on the pin is complete, the pin description handle will be released.
+    -   Setting or obtaining the pull type of a pin: The pull type can be pull-up, pull-down, or floating.
+    -   Setting or obtaining the pull strength of a pin: You can set the pull strength as required.
+    -   Setting or obtaining the functions of a pin to implement pin multiplexing
+
+### Basic Concepts<a name="section3"></a>
+Pin, as a software concept, provides APIs for uniformly managing the pins from different SoC vendors, providing the pin multiplexing function, and configuring the electrical features of pins.
+
+- SoC
+
+  An SOC is a chip that integrates microprocessors, analog IP cores, digital IP cores, and memory for specific purposes.
+
+- Pin multiplexing
+
+  When the number of pins of a chip cannot handle the increasing connection requests, you can set the software registers to make the pins to work in different states.
+
+### Working Principles<a name="section4"></a>
+
+In the HDF, the pin module does not support the user mode and therefore does not need to publish services. It uses the service-free mode in interface adaptation. The service-free mode applies to the devices that do not provide user-mode APIs or the OS that does not distinguish the user mode and the kernel mode. The **DevHandle**, a void pointer, directly points to the kernel mode address of the device object.
+
+The pin module is divided into the following layers:
+-   Interface layer: provides APIs for obtaining a pin, setting or obtaining the pull type, pull strength, and functions of a pin, and releasing a pin.
+-   Core layer: provides the capabilities of matching pin resources and adding, removing, and managing pin controllers. The core layer interacts with the adaptation layer by using hooks.
+-   Adaptation layer: instantiates hooks to implement specific functions.
+
+**Figure 1** Service-free mode<a name="fig14423182615525"></a> 
+![](figures/service-free-mode.png "pin service-free mode")
+
+### Constraints<a name="section5"></a>
+
+ Currently, the pin module supports only the kernels (LiteOS) of mini and small systems.
+
+ ## Usage Guidelines<a name="section6"></a>
+
+ ### When to Use<a name="7"></a>
+
+  The pin module is a software concept and is used to manage pin resources. You can set the functions, pull type, and pull strength of pins to implement pin multiplexing.
+
+### Available APIs<a name="section8"></a>
+
+The table below describes the APIs of the pin module. For more details, see API Reference.
+
+**Table 1** Pin driver APIs
+<a name="table1"></a>
+
+| **API**                                                  | **Description**        |
+| ------------------------------------------------------------ | ---------------- |
+| DevHandle PinGet(const char *pinName);                       | Obtains the pin description handle.|
+| void PinPut(DevHandle handle);                               | Releases the pin description handle.|
+| int32_t PinSetPull(DevHandle handle, enum PinPullType pullType); | Sets the pull type of a pin.|
+| int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType); | Obtains the pull type of a pin.|
+| int32_t PinSetStrength(DevHandle handle, uint32_t strength); | Sets the pull strength of a pin.|
+| int32_t PinGetStrength(DevHandle handle, uint32_t *strength); | Obtains the pull strength of a pin.|
+| int32_t PinSetFunc(DevHandle handle, const char *funcName);  | Sets the pin function.    |
+| int32_t PinGetFunc(DevHandle handle, const char **funcName); | Obtains the pin functions.    |
+
+>![](../public_sys-resources/icon-note.gif) **NOTE**<br/>
+>All APIs described in this document can be called only in the kernel space.
+
+### How to Develop<a name="section9"></a>
+
+The figure below shows the process.
+
+ **Figure 2** Process of using the pin module<a name="fig2"></a> 
+![](figures/process-of-using-pin.png "Process of using the pin module")
+
+#### Obtaining the Pin Description Handle
+
+Before performing an operation on a pin, call **PinGet** to obtain the pin description handle. This API returns the pin description handle that matches the input pin name.
+
+```
+DevHandle PinGet(const char *pinName);
+```
+
+**Table 2** Description of PinGet
+
+<a name="table2"></a>
+
+| Parameter      | Description               |
+| ---------- | ----------------------- |
+| pinName    | Pointer to the pin name.                 |
+| **Return Value**| **Description**         |
+| NULL       | Failed to obtain the pin description handle.|
+| handle     | Pin description handle obtained.        |
+
+Example: Obtain the handle of P18.
+
+```
+DevHandle handle = NULL;               /* Pin description handle */
+char pinName = "P18";                 /* Pin name. */
+handle = PinGet(pinName);
+if (handle == NULL) {
+    HDF_LOGE("PinGet: get handle failed!\n");
+    return;
+}
+```
+
+#### Setting the Pull Type of a Pin
+
+Call **PinSetPull** to set the pull type of a pin. 
+
+```
+int32_t PinSetPull(DevHandle handle, enum PinPullType pullType);
+```
+
+**Table 3** Description of PinSetPull
+
+<a name="table3"></a>
+
+| Parameter      | Description               |
+| ---------- | ----------------------- |
+| handle     | Pin description handle.        |
+| pullType   | Pull type to set.        |
+| **Return Value**| **Description**         |
+| 0          | The operation is successful.|
+| Negative value      | The operation fails.|
+
+Example: Set the pull type to pull-up.
+
+```
+int32_t ret;
+enum PinPullType pullTypeNum;
+/* Set the pull type of a pin. */
+pullTypeNum = 1;
+ret = PinSetPull(handle, pullTypeNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinSetPull: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Obtaining the Pull Type of a Pin
+
+Call **PinGetPull** to obtain the pull type of a pin.
+
+```
+int32_t PinGetPull(DevHandle handle, enum PinPullType *pullType);
+```
+
+**Table 4** Description of PinGetPull
+
+<a name="table4"></a>
+
+| Parameter      | Description                 |
+| ---------- | ------------------------- |
+| handle     | Pin description handle.          |
+| pullType   | Pointer to the pull type obtained.|
+| **Return Value**| **Description**           |
+| 0          | The operation is successful.  |
+| Negative value      | The operation fails.  |
+
+Example: Obtain the pull type of a pin.
+
+```
+int32_t ret;
+enum PinPullType pullTypeNum;
+/* Obtain the pull type of a pin.  */
+ret = PinGetPull(handle, &pullTypeNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinGetPull: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Setting the Pull Strength of a Pin
+
+Call **PinSetStrength** to set the pull type of a pin.
+
+```
+int32_t PinSetStrength(DevHandle handle, uint32_t strength);
+```
+
+**Table 5** Description of PinSetStrength
+
+<a name="table5"></a>
+
+| Parameter      | Description               |
+| ---------- | ----------------------- |
+| handle     | Pin description handle.           |
+| strength   | Pull strength to set.        |
+| **Return Value**| **Description**         |
+| 0          | The operation is successful.|
+| Negative value      | The operation fails.|
+
+Example: Set the pull strength of the pin to 2. 
+
+```
+int32_t ret;
+uint32_t strengthNum;
+/* Set the pull strength of the pin. */
+strengthNum = 2;
+ret = PinSetStrength(handle, strengthNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinSetStrength: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Obtaining the Pull Strength of a Pin
+
+Call **PinGetStrength** to obtain the pull strength set.
+
+```
+int32_t PinGetStrength(DevHandle handle, uint32_t *strength);
+```
+
+**Table 6** Description of PinGetStrength
+
+<a name="table6"></a>
+
+| Parameter      | Description                 |
+| ---------- | ------------------------- |
+| handle     | Pin description handle.             |
+| strength   | Pointer to the pull strength obtained.|
+| **Return Value**| **Description**           |
+| 0          | The operation is successful.  |
+| Negative value      | The operation fails.  |
+
+Example: Obtain the pull strength of a pin.
+
+```
+int32_t ret;
+uint32_t strengthNum;
+/* Obtain the pull strength of the pin. */
+ret = PinGetStrength(handle, &strengthNum);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinGetStrength: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Setting the Pin Function
+
+The pin function refers to the pin multiplexing function. The function of each pin is different. For details about the pin functions, see [pin_config.hcs](https://gitee.com/openharmony/device_soc_hisilicon/blob/master/hi3516dv300/sdk_liteos/hdf_config/pin/pin_config.hcs).
+
+Call **PinSetFunc** to set the pin function.
+
+```
+int32_t PinSetFunc(DevHandle handle, const char *funcName);
+```
+
+**Table 7** Description of PinSetFunc
+
+<a name="table7"></a>
+
+| Parameter      | Description           |
+| ---------- | ------------------- |
+| handle     | Pin description handle.       |
+| funcName   | Pointer to the pin function to set.      |
+| **Return Value**| **Description**     |
+| 0          | The operation is successful.|
+| Negative value      | The operation fails.|
+
+Example: Set the pin function to LSADC_CH1 (ADC channel 1).
+
+```
+int32_t ret;
+char funcName = "LSADC_CH1";
+/* Sets the pin function. */
+ret = PinSetFunc(handle, funcName);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinSetFunc: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+#### Obtaining the Pin Function
+
+Call **PinGetFunc** to obtain the pin function set.
+
+```
+int32_t PinGetFunc(DevHandle handle, const char **funcName);
+```
+
+**Table 8** Description of PinGetFunc
+
+<a name="table8"></a>
+
+| Parameter      | Description             |
+| ---------- | --------------------- |
+| handle     | Pin description handle.         |
+| funcName   | Pointer to the function name obtained.|
+| **Return Value**| **Description**       |
+| 0          | The operation is successful.  |
+| Negative value      | The operation fails.  |
+
+Example: Obtain the pin function. 
+
+```
+int32_t ret;
+char *funcName;
+/* Obtain the pin function. */
+ret = PinGetFunc(handle,&funcName);
+if (ret != HDF_SUCCESS) {
+    HDF_LOGE("PinGetFunc: failed, ret %d\n", ret);
+    return ret;
+}
+```
+
+####  Releasing a Pin Description Handle
+
+After the operations on a pin are complete, call **PinPut** to release the pin description handle.
+
+```
+void PinPut(DevHandle handle);
+```
+
+**Table 9** Description of PinPut
+
+<a name="table9"></a>
+
+| Parameter      | Description      |
+| ---------- | -------------- |
+| handle     | Pin description handle.  |
+| **Return Value**| **Description**|
+| NA         | No value is returned.      |
+
+Example: Release a pin description handle.
+
+``` 
+PinPut(handle);
+```
+
+## Development Example<a name="section10"></a>
+
+The procedure is as follows:
+1. Pass in the pin name to obtain the pin description handle.
+2. Set the pull type of the pin. If the operation fails, release the pin description handle.
+3. Obtain the pull type of the pin. If the operation fails, release the pin description handle.
+4. Set the pull strength of the pin. If the operation fails, release the pin description handle.
+5. Obtain the pin pull strength. If the operation fails, release the pin description handle.
+5. Set the pin function. If the operation fails, release the pin description handle.
+6. Obtain the pin function. If the operation fails, release the pin description handle.
+7. Release the pin description handle if no operation needs to be performed on the pin.
+
+```
+#include "hdf_log.h"         /* Header file for log APIs */
+#include "pin_if.h"   /* Header file for standard pin APIs */
+
+int32_t PinTestSample(void)
+{
+    int32_t ret;
+    uint32_t strengthNum;
+    enum PinPullType pullTypeNum;
+    char pinName;
+    char *funName;
+    DevHandle handle = NULL;
+
+    /* Pin name. Set it to the actual pin name. */
+    pinName = "P18"; 
+    /* Obtain the pin description handle. */
+    handle = PinGet(pinName);
+    if (handle == NULL) {
+        HDF_LOGE("PinGet: failed!\n");
+        return;
+    }
+    /* Set the pull type to pull-up for the pin. */
+    pullTypeNum = 1;
+    ret = PinSetPull(handle, pullTypeNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinSetPull: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Obtain the pull type of the pin. */
+    ret = PinGetPull(handle, &pullTypeNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinGetPull: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Set the pull strength of the pin to 2. */
+    strengthNum = 2;
+    ret = PinSetStrength(handle, strengthNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinSetStrength: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Obtain the pull strength of the pin. */
+    ret = PinGetStrength(handle, &strengthNum);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinGetStrength: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Set the pin function to LSADC_CH1. */
+    funName = "LSADC_CH1";
+    ret = PinSetFunc(handle, funName);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinSetFunc: failed, ret %d\n", ret);
+        goto ERR;
+    }
+    /* Obtain the pin function. */
+    ret = PinGetFunc(handle, &funcName);
+    if (ret != HDF_SUCCESS) {
+        HDF_LOGE("PinGetFunc: failed, ret %d\n", ret);
+        goto ERR;
+    }
+ERR:
+    /* Release the pin description handle. */
+    PinPut(handle); 
+    return ret;
+}

en/device-dev/driver/driver-platform.md

@@ -2,6 +2,8 @@
 
 -   **[ADC](driver-platform-adc-des.md)**  
 
+-   **[DAC](driver-platform-dac-des.md)**  
+
 -   **[GPIO](driver-platform-gpio-des.md)**  
 
 -   **[HDMI](driver-platform-hdmi-des.md)**  
@@ -14,6 +16,8 @@
 
 -   **[MIPI DSI](driver-platform-mipidsi-des.md)**  
 
+-   **[Pin](driver-platform-pin-des.md)**
+
 -   **[PWM](driver-platform-pwm-des.md)**  
 
 -   **[RTC](driver-platform-rtc-des.md)**