!5857 [翻译完成】#I5A5B0

Merge pull request !5857 from Annie_wang/PR4732

!5857 [翻译完成】#I5A5B0
Merge pull request !5857 from Annie_wang/PR4732
2b86ed88 · openharmony_ci · Gitee · 54066285 · e492d745 · 2b86ed88
8 changed file
--- a/en/device-dev/driver/Readme-EN.md
+++ b/en/device-dev/driver/Readme-EN.md
@@ -45,13 +45,13 @@
 - Peripheral Driver Usage
  - [Audio](driver-peripherals-audio-des.md)
  - [Camera](driver-peripherals-camera-des.md)
-  - [Face_auth](driver-peripherals-face_auth-des.md)
+  - [Facial Authentication](driver-peripherals-face_auth-des.md)
  - [LCD](driver-peripherals-lcd-des.md)
  - [Light](driver-peripherals-light-des.md)
-  - [Pin_auth](driver-peripherals-pinauth-des.md)
+  - [PIN Authentication](driver-peripherals-pinauth-des.md)
  - [Sensor](driver-peripherals-sensor-des.md)
  - [Touchscreen](driver-peripherals-touch-des.md)
  - [USB](driver-peripherals-usb-des.md)
-  - [User_auth](driver-peripherals-user-auth-des.md)
+  - [User Authentication](driver-peripherals-user-auth-des.md)
  - [Vibrator](driver-peripherals-vibrator-des.md)
  - [WLAN](driver-peripherals-external-des.md)
--- a/en/device-dev/driver/driver-peripherals-face_auth-des.md
+++ b/en/device-dev/driver/driver-peripherals-face_auth-des.md
-# Face_auth
+# Facial Authentication
 ## Overview
 ### Function
-Facial authentication provides user authentication capabilities in identity authentication scenarios, such as device unlocking, payment, and app logins. It uses biometric recognition technologies to identify individuals based on facial characteristics. A camera is used to collect images or video streams that contain human faces, and automatically detect, track, and recognize human faces. Facial authentication is also called facial recognition or face recognition. The figure below shows the architecture of facial authentication.
+Facial authentication provides user authentication capabilities in identity authentication scenarios, such as device unlocking, payment, and app logins. It uses biometric recognition technologies to identify individuals based on facial characteristics. A camera is used to collect images or video streams that contain human faces, and automatically detect, track, and recognize human faces. Facial authentication is also called facial recognition. The figure below shows the architecture of facial authentication.
-The face authentication driver (Face_auth) driver is developed based on the Hardware Driver Foundation (HDF) driver framework. It shields hardware differences and provides stable facial authentication capabilities for the user authentication framework (User_auth) and Face_auth service. The facial authentication capabilities include obtaining facial recognition executor list, executor information, and template information by template ID, comparing face image template information of the executor and that of User_auth, enrolling or deleting face templates, and performing facial authentication.
+The face authentication (Face_auth) driver is developed based on the Hardware Driver Foundation (HDF). It shields hardware differences and provides stable facial authentication capabilities for the user authentication framework (User_auth) and Face_auth service. The facial authentication capabilities include obtaining facial recognition executor list, executor information, and template information by template ID, comparing face image template information of the executor and that of User_auth, enrolling or deleting face image templates, and performing facial authentication.
 **Figure 1** Facial authentication architecture
@@ -14,14 +14,14 @@ The face authentication driver (Face_auth) driver is developed based on the Hard
 ### Basic Concepts
-The identity authentication consists of User_auth and basic authentication services (including PIN authentication and facial authentication). It supports basic functions such as setting and deleting user credentials and performing authentication. The system supports user identity authentication and provides data collection, processing, storage, and comparison capabilities.
+The identity authentication consists of User_auth and basic authentication services (including PIN authentication and facial authentication). It supports basic functions such as setting and deleting user credentials and performing authentication. The system supports user identity authentication and data collection, processing, storage, and comparison.
 - Executor
  The executor collects, processes, stores, and compares data for authentication. Each authentication service provides the executor capabilities, which are scheduled by User_auth to implement basic capabilities.
 - Executor security level
-  Certain security level is required for the execution environment of an executor. For example, the executor security level is low for an operation performed without access control and high for an operation performed in a Trusted Execution Environment (TEE).
+  Security level required for the execution environment of an executor.
 - Executor role
@@ -39,11 +39,11 @@ The identity authentication consists of User_auth and basic authentication servi
  To ensure user data security and authentication result accuracy, measures must be taken to protect the integrity of the key information exchanged between User_auth and basic authentication services. Public keys must be exchanged when the executor provided by a basic authentication service interworks with User_auth.
-    The executor uses the User_auth public key to verify scheduling instructions. For example, if a face image template is locked, the related facial authentication capability cannot be used. The instruction for unlocking the face image template must be verified before being executed.
+    The executor uses the User_auth public key to verify scheduling instructions.
    User_auth uses the executor public key to verify the authentication result accuracy and the integrity of the information exchanged with the executor.
- Facial authentication credential template
+- Authentication credential template
  Authentication credentials are generated and stored by the authentication service when users set authentication credentials. Each template has an ID to index a set of template information files. The template information needs to be compared with the authentication data generated during authentication to complete identity authentication.
@@ -53,7 +53,7 @@ The identity authentication consists of User_auth and basic authentication servi
 ### Working Principles
-The Face_auth driver provides basic facial authentication capabilities for the User_auth framework and Face_auth service to ensure successful facial authentication.
+The Face_auth driver provides basic facial authentication capabilities for the User_auth and Face_auth service to ensure successful facial authentication.
 You can develop drivers to call Hardware Device Interface (HDI) APIs based on the HDF and the chip you use.
 **Figure 2** Face_auth service and Face_auth driver interaction
@@ -62,15 +62,15 @@ You can develop drivers to call Hardware Device Interface (HDI) APIs based on th
 ### Constraints
- To implement facial authentication, the device must have a camera with a face image pixel greater than 100x100.
+- To implement facial authentication, the device must have a camera and the face image must be greater than 100 x 100 pixels.
- TEE must be available, and facial feature information must be encrypted and stored in a TEE.
+- A Trusted Execution Environment (TEE) must be available, and facial feature information must be encrypted and stored in a TEE.
 - The face matching accuracy varies with people with similar looks and children whose facial features keep changing. If you are concerned about this, consider using other authentication modes.
 ## Development Guidelines
 ### When to Use
-The Face_auth driver provides basic facial authentication capabilities for the User_auth framework and Face_auth service to ensure successful facial authentication.
+The Face_auth driver provides basic facial authentication capabilities for the User_auth and Face_auth service to ensure successful facial authentication.
 ### Available APIs
@@ -79,12 +79,12 @@ The Face_auth driver provides basic facial authentication capabilities for the U
 | API                                                      | Description                                                    |
 | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | GetExecutorList(std::vector<sptr<IExecutor>>& executorList)  | Obtains the executor list.                                            |
-| GetExecutorInfo(ExecutorInfo& info)                          | Obtain the executor information, including the executor type, executor role, authentication type, security level, and executor public key.|
+| GetExecutorInfo(ExecutorInfo& info)                          | Obtains the executor information, including the executor type, executor role, authentication type, security level, and executor public key.|
 | GetTemplateInfo(uint64_t templateId, TemplateInfo& info)     | Obtains information about a face image template based on the specified template ID.                              |
 | OnRegisterFinish(const std::vector<uint64_t>& templateIdList,<br>        const std::vector<uint8_t>& frameworkPublicKey, const std::vector<uint8_t>& extraInfo) | Obtains the public key and template ID list from User_auth after the executor is registered successfully.|
 | Enroll(uint64_t scheduleId, const std::vector<uint8_t>& extraInfo,<br>        const sptr<IExecutorCallback>& callbackObj) | Enrolls a face image template.                                              |
 | Authenticate(uint64_t scheduleId, const std::vector<uint64_t>& templateIdList,<br>        const std::vector<uint8_t>& extraInfo, const sptr<IExecutorCallback>& callbackObj) | Performs facial authentication.                                              |
-| Identify(uint64_t scheduleId, const std::vector<uint8_t>& extraInfo,<br>        const sptr<IExecutorCallback>& callbackObj) | Performs face identification.                                              |
+| Identify(uint64_t scheduleId, const std::vector<uint8_t>& extraInfo,<br>        const sptr<IExecutorCallback>& callbackObj) | Performs facial identification.                                              |
 | Delete(const std::vector<uint64_t>& templateIdList)          | Deletes a face image template.                                              |
 | Cancel(uint64_t scheduleId)                                  | Cancels a face enrolling, authentication, or identification operation based on the **scheduleId**.                |
 | SendCommand(int32_t commandId, const std::vector<uint8_t>& extraInfo,<br>        const sptr<IExecutorCallback>& callbackObj) | Sends commands to the Face_auth service.             |
@@ -98,7 +98,7 @@ The Face_auth driver provides basic facial authentication capabilities for the U
 ### How to Develop
-The following uses the Hi3516DV300 platform as an example to demonstrate how to develop the Face_auth driver. <br/>The directory structure is as follows:
+The following uses the Hi3516D V300 development board as an example to demonstrate how to develop the Face_auth driver. <br/>The directory structure is as follows:
 ```undefined
 // drivers/peripheral/face_auth
@@ -118,7 +118,7 @@ The development procedure is as follows:
 1. Develop the Face_auth driver based on the HDF. The **Bind()**, **Init()**, **Release()**, and **Dispatch()** functions are used. For details about the code, see [face_auth_interface_driver.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/face_auth/hdi_service/src/face_auth_interface_driver.cpp).
   ```c++
-   // Create the IRemoteObject object by using the custom HdfFaceAuthInterfaceHost object, which consists of the IoService object and HDI service.
+   // Create an IRemoteObject object by using the custom HdfFaceAuthInterfaceHost object, which consists of the IoService object and HDI service.
   struct HdfFaceAuthInterfaceHost {
       struct IDeviceIoService ioService;
       OHOS::sptr<OHOS::IRemoteObject> stub;
@@ -152,6 +152,10 @@ The development procedure is as follows:
   int HdfFaceAuthInterfaceDriverInit(struct HdfDeviceObject *deviceObject)
   {
       IAM_LOGI("start");
+       if (!HdfDeviceSetClass(deviceObject, DEVICE_CLASS_USERAUTH)) {
+           IAM_LOGE("set face auth hdf class failed");
+           return HDF_FAILURE;
+       }
       return HDF_SUCCESS;
   }
@@ -161,7 +165,7 @@ The development procedure is as follows:
       IAM_LOGI("start");
       auto *hdfFaceAuthInterfaceHost = new (std::nothrow) HdfFaceAuthInterfaceHost;
       if (hdfFaceAuthInterfaceHost == nullptr) {
-           IAM_LOGE("%{public}s: failed to create create HdfFaceAuthInterfaceHost object", __func__);
+           IAM_LOGE("%{public}s: Failed to create HdfFaceAuthInterfaceHost object", __func__);
           return HDF_FAILURE;
       }
@@ -171,7 +175,7 @@ The development procedure is as follows:
       auto serviceImpl = IFaceAuthInterface::Get(true);
       if (serviceImpl == nullptr) {
-           IAM_LOGE("%{public}s: Failed to implement the service", __func__);
+           IAM_LOGE("%{public}s: Failed to implement service", __func__);
           return HDF_FAILURE;
       }
@@ -271,7 +275,7 @@ The development procedure is as follows:
   {
       IAM_LOGI("interface mock start");
       info = executorInfo_;
-       IAM_LOGI("get executor information success");
+       IAM_LOGI("Executor information got successfully");
       return HDF_SUCCESS;
   }
@@ -281,7 +285,7 @@ The development procedure is as follows:
       IAM_LOGI("interface mock start");
       static_cast<void>(templateId);
       info = {0};
-       IAM_LOGI("get template information success");
+       IAM_LOGI("Template information got successfully");
       return HDF_SUCCESS;
   }
@@ -293,11 +297,11 @@ The development procedure is as follows:
       static_cast<void>(templateIdList);
       static_cast<void>(extraInfo);
       static_cast<void>(frameworkPublicKey);
-       IAM_LOGI("register finish");
+       IAM_LOGI("Registration finished");
       return HDF_SUCCESS;
   }
-   // Enroll face image.
+   // Enroll a face image.
   int32_t Enroll(uint64_t scheduleId, const std::vector<uint8_t>& extraInfo,
       const sptr<IExecutorCallback>& callbackObj)
   {
@@ -330,7 +334,7 @@ The development procedure is as follows:
       return HDF_SUCCESS;
   }
-   // Perform face recognition.
+   // Perform facial recognition.
   int32_t Identify(uint64_t scheduleId, const std::vector<uint8_t>& extraInfo,
       const sptr<IExecutorCallback>& callbackObj)
   {
@@ -364,7 +368,7 @@ The development procedure is as follows:
       return HDF_SUCCESS;
   }
-   // Send template freezing or unlocking command from the Face_auth service to the Face_auth driver.
+   // Send template locking or unlocking command from the Face_auth service to the Face_auth driver.
   int32_t SendCommand(int32_t commandId, const std::vector<uint8_t>& extraInfo,
       const sptr<IExecutorCallback>& callbackObj)
   {
@@ -417,7 +421,7 @@ The development procedure is as follows:
 ### Verification
-Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516DV300 platform. The sample code for verifying the authentication and authentication cancellation is as follows:
+Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516D V300 development board. The sample code for verifying and canceling the authentication is as follows:
 ```js
 // API version 8
@@ -426,7 +430,7 @@ let auth = new userIAM_userAuth.UserAuth();
 export default {
    getVersion() {
-        console.info("start get version");
+        console.info("start to get version");
        let version = this.auth.getVersion();
        console.info("auth version = " + version);
    },
@@ -438,7 +442,7 @@ export default {
                try {
                    console.info("auth onResult result = " + result);
                    console.info("auth onResult extraInfo = " + JSON.stringify(extraInfo));
-                    if (result == 'SUCCESS') {
+                    if (result == userIAM_userAuth.ResultCode.SUCCESS) {
                        // Add the logic to be executed when the authentication is successful.
                    }  else {
                        // Add the logic to be executed when the authentication fails.
@@ -473,10 +477,10 @@ export default {
            }
        });
        let cancelCode = this.auth.cancel(contextId);
-        if (cancelCode == userIAM_userAuth.Result.SUCCESS) {
+        if (cancelCode == userIAM_userAuth.ResultCode.SUCCESS) {
-            console.info("cancel auth success");
+            console.info("Authentication canceled successfully");
        } else {
-            console.error("cancel auth fail");
+            console.error("failed to cancel authentication");
        }
    }
 }

--- a/en/device-dev/driver/driver-peripherals-lcd-des.md
+++ b/en/device-dev/driver/driver-peripherals-lcd-des.md
-# LCD<a name="EN-US_TOPIC_0000001052857284"></a>
+# LCD
-## Overview<a name="section141575391542"></a>
-The Liquid Crystal Display \(LCD\) driver powers on the LCD and initializes internal LCD registers through APIs to enable the LCD to work properly. The display driver is developed based on the hardware driver foundation \([HDF](driver-hdf-overview.md)\). It provides power-on, power-off, and sending of the initialization sequence for LCD hardware across OSs and platforms. The display driver model is shown in  [Figure 1](#fig69138814229).
+## Overview
-**Figure  1**  Architecture of the display driver model<a name="fig69138814229"></a>  
+The Liquid Crystal Display (LCD) driver performs operations such as powering on the LCD and initializing the internal registers of the driver integrated circuits (ICs).
-![](figures/architecture-of-the-display-driver-model.png "architecture-of-the-display-driver-model")
-**Display Driver Model**
+The display driver model developed based on the Hardware Driver Foundation [(HDF)](driver-hdf-overview.md) provides a basic framework for LCD driver development, improves driver development efficiency, and facilitates porting of the driver across OSs and chip platforms. The figure below shows the HDF-based display driver model.
-The display driver model consists of the display common driver layer, SoC adapter layer, and third-party chip driver layer. The display driver model is developed based on the HDF and hides the differences between kernel forms through platform and OSAL APIs so the LCD driver can be migrated between different OSs and chip platforms. The display driver connects to the display common HAL, supports the implementation of Hardware Device Interfaces \(HDIs\), and provides various driver interfaces for the graphics service through the display HDI.
-   HDF display driver layer: connects to the display common HAL through the IOService data channel provided by the HDF to receive and process various upper-layer calls in a centralized manner.
+  **Figure 1** HDF-based display driver model
-   SoC adapter layer: decouples the display driver from the SoC driver, configures parameters related to the chip platform, and passes the calls at the platform driver layer to the LCD driver layer.
-   LCD panel driver layer: provides LCD-related APIs for sending the initialization sequence, powering on/off, and setting the backlight.
-The display driver model, capabilities, and APIs help you simplify the display driver development and improve the efficiency.
+  ![image](figures/architecture-of-the-display-driver-model.png "Display Driver Model")
-## API Description<a name="section53793327396"></a>
-The LCD interfaces are classified into the Mobile Industry Processor Interface \(MIPI\) Display Serial Interface \(DSI\), Transistor-Transistor Logic \(TTL\) interfaces, and Low Voltage Differential Signaling \(LVDS\) interfaces. The MIPI DSI and TTL interfaces are commonly used. Here is a brief introduction to them.
+The display driver model consists of the display common driver layer, SoC adapter layer, and LCD panel driver layer. The HDF-based display driver model shields the differences between kernel forms through platform and OSAL APIs so the LCD driver can be easily ported between different OSs and chip platforms. The display driver model connects to the display common Hardware Abstraction Layer (HAL), supports the implementation of the Hardware Device Interface (HDI), and provides various driver capability interfaces for graphics services through the Display-HDI.
-   MIPI DSI
+- Display common driver layer: connects to the display common HAL through the IOService data channel provided by the HDF to receive and process various upper-layer calls in a centralized manner.
-    **Figure  2**  MIPI DSI<a name="fig6936451331"></a>  
+- SoC adapter layer: decouples the display driver from the SoC driver, configures parameters related to the chip platform, and passes the calls from the platform driver layer to the LCD driver layer.
-    ![](figures/mipi-dsi.png "mipi-dsi")
-    The MIPI DSI is defined by MIPI Alliance. It is mainly used for mobile terminal display. The MIPI DSI is used to transmit image data, in compliance with the MIPI protocol. Generally, control information of the MIPI DSI is sent to the peer IC in the form of MIPI packets through the MIPI DSI. No additional interface is required.
+- LCD panel driver layer: provides LCD-related APIs for sending the initialization sequence, powering on/off, and setting the backlight.
-   TTL interface
+The display driver model leverages the capabilities and APIs provided by the platform to simplify the display driver development and improve the efficiency.
+## Available APIs
+The LCD interfaces include the Mobile Industry Processor Interface (MIPI) Display Serial Interface (DSI), Transistor-Transistor Logic (TTL) interface, and Low Voltage Differential Signaling (LVDS) interface. The MIPI DSI and TTL interfaces are commonly used. Here is a brief introduction to them.
+- MIPI DSI
+    **Figure 2** MIPI DSI
+    ![](figures/mipi-dsi.png "MIPI DSI")
+  The DSI is defined by the MIPI Alliance for the displays used in mobile devices. The MIPI DSI is used to transmit image data, in compliance with the MIPI protocol. Generally, control information is sent to the peer IC in the form of MIPI packets over the MIPI DSI, without the need of additional peripheral interfaces.
+- TTL interface
+    **Figure 3** TTL interface
-    **Figure  3**  TTL interface<a name="fig141611855635"></a>  
    ![](figures/ttl-interface.png "ttl-interface")
-    TTL level signals are generated by TTL devices, which are a major type of digital integrated circuits. They are manufactured using the bipolar process and feature high speed, low power consumption, and multiple types.
+  TTL level signals are generated by TTL devices, which are a major type of digital integrated circuits. TTL devices are manufactured using the bipolar process and feature high speed, low power consumption, and diversified types.
+  The TTL interface is used to transmit data in parallel mode under control signals. It transmits data signals, clock signals, and control signals (such as line synchronization signals, frame synchronization signals, and data validity signals). For the LCD with the TTL, additional peripheral interfaces, such as the Serial Peripheral Interface (SPI) and Inter-Integrated Circuit (I2C), are required for the read and write of the internal registers.
+## How to Develop
-    The TTL interface is used to transmit data in parallel mode under the control of control signals. It transmits data signals, clock signals, and control signals \(such as line synchronization signals, frame synchronization signals, and data validity signals\). Generally, the LCD of the TTL interface and the read/write of internal registers require additional peripheral interfaces, such as the Serial Peripheral Interface \(SPI\) and Inter-Integrated Circuit \(I2C\).
+The HDF-based display driver model provides a unified driver model for LCDs regardless of the OS (LiteOS or Linux OS) and chip platform (Hi35xx, Hi38xx, or V3S). The development procedure is as follows:
-## How to Develop<a name="section12394223125615"></a>
+1. Add the device configuration related to the LCD driver.
-The display driver model is developed based on the HDF, platform APIs, and APIs at the OS abstraction layer \(OSAL\), and provides a unified driver model for the LCD regardless of the OS \(LiteOS or Linux OS\) and chip platforms \(such as Hi35xx, Hi38xx, and V3S\).
+2. Adapt the driver to the chip at the SoC adapter layer.
-1.  Add the LCD driver-related hardware descriptions.
+3. Add the LCD panel driver and register the panel driver functions in the driver entry function **Init**. The functions provide capabilities for:
-2.  Add a driver that adapts to the chip at the SoC adapter layer.
+   - Powering on/off the LCD device
-3.  Add the LCD panel driver and register the panel driver functions in the driver entry function  **Init**. The functions provide capabilities for:
+      Based on the LCD hardware connection, use the GPIO APIs provided by the platform to perform operations on the LCD pins, such as the reset pin and IOVCC pin. For details about the power-on sequence, see the SPEC provided by the LCD supplier.
-    -   Powering on/off the LCD device
+   - Sending the initialization sequence
+      Based on the LCD hardware interfaces, use the I2C, SPI, and MIPI interfaces provided by the platform to download the LCD initialization sequence. For details, see the SPEC provided by the LCD supplier.
-        Based on the LCD hardware connection, use the GPIO interfaces provided by the platform to perform operations on the LCD pins, such as the reset pin and IOVCC pin. For details about the power-on sequence, see the SPEC provided by the LCD supplier.
+4. Implement other HDF APIs as required, for example, **Release()**.
-    -   Sending the initialization sequence
+5. Use the HDF to create other device nodes for implementing service logic or debugging as required.
-        Based on the LCD hardware interfaces, use the I2C, SPI, and MIPI interfaces provided by the platform to download the LCD initialization sequence. For details, see the SPEC provided by the LCD supplier.
-4.  Implement other HDF interfaces as required, for example, the  **Release**  interface.
+## Development Example
-5.  Use the HDF to create other device nodes for implementing service logic or debugging as required.
-## Development Example<a name="section7441155155813"></a>
+Add the device configuration.
-Add the device description.
 ```
-/* Description of the display driver */
+/* Configuration of the devices related to the display driver */
 display :: host {
    hostName = "display_host";
-    /* Description of the HDF display driver */
+    /* Configuration of the HDF display driver */
    device_hdf_disp :: device {
        device0 :: deviceNode {
            policy = 2;
@@ -74,7 +86,7 @@ display :: host {
            serviceName = "hdf_disp";
        }
    }
-    /* Description of the driver device at the SoC adapter layer */
+    /* Configuration of the driver device at the SoC adapter layer */
    device_hi35xx_disp :: device {
        device0 :: deviceNode {
            policy = 0;
@@ -82,7 +94,7 @@ display :: host {
            moduleName = "HI351XX_DISP";
        }
    }
-    /* Description of the LCD driver */
+    /* Configuration of the LCD driver */
    device_lcd :: device {
        device0 :: deviceNode {
            policy = 0;
@@ -100,7 +112,8 @@ display :: host {
 }
 ```
-The following example shows how to adapt the MIPI device to the Hi35xx series chips at the SoC adapter layer:
+Adapt the driver to the chip at the SoC adapter layer. The following example shows how to adapt the MIPI device to the Hi35xx series chips at the SoC adapter layer:
 ```
 static int32_t MipiDsiInit(struct PanelInfo *info)
@@ -130,7 +143,7 @@ static int32_t MipiDsiInit(struct PanelInfo *info)
    cfg.timing.edpiCmdSize = 0;
    cfg.pixelClk = CalcPixelClk(info);
    cfg.phyDataRate = CalcDataRate(info);
-    /* config mipi device */
+    /* Configure the MIPI device. */
    ret = MipiDsiSetCfg(mipiHandle, &cfg);
    if (ret != HDF_SUCCESS) {
        HDF_LOGE("%s:MipiDsiSetCfg failure", __func__);
@@ -142,14 +155,15 @@ static int32_t MipiDsiInit(struct PanelInfo *info)
 }
 ```
-The following example shows code for developing an LCD driver:
+Develop an LCD driver. The sample code is as follows:
 ```
 #define RESET_GPIO                5
 #define MIPI_DSI0                 0
 #define BLK_PWM1                  1
 #define PWM_MAX_PERIOD            100000
-/* backlight setting */
+/* Set the backlight. */
 #define MIN_LEVEL                 0
 #define MAX_LEVEL                 255
 #define DEFAULT_LEVEL             100
@@ -249,14 +263,14 @@ static int32_t LcdResetOn(void)
        HDF_LOGE("GpioWrite failure, ret:%d", ret);
        return HDF_FAILURE;
    }
-    /* delay 20ms */
+    /* Set the delay to 20 ms. */
    OsalMSleep(20);
    return HDF_SUCCESS;
 }
 static int32_t SampleInit(void)
 {
-    /* Obtain the MIPI DSI device handle. */
+    /* Open the MIPI DSI device handle. */
    g_mipiHandle = MipiDsiOpen(MIPI_DSI0);
    if (g_mipiHandle == NULL) {
        HDF_LOGE("%s: MipiDsiOpen failure", __func__);
@@ -306,7 +320,7 @@ static struct PanelInfo g_panelInfo = {
    .frameRate = FRAME_RATE,            /* frame rate */
    .intfType = MIPI_DSI,               /* panel interface type */
    .intfSync = OUTPUT_USER,            /* output timming type */
-    /* mipi config info */
+    /* MIPI configuration */
    .mipi = { DSI_2_LANES, DSI_VIDEO_MODE, VIDEO_BURST_MODE, FORMAT_RGB_24_BIT },
    /* backlight config info */
    .blk = { BLK_PWM, MIN_LEVEL, MAX_LEVEL, DEFAULT_LEVEL },
@@ -330,7 +344,7 @@ int32_t SampleEntryInit(struct HdfDeviceObject *object)
        HDF_LOGE("%s: param is null!", __func__);
        return HDF_FAILURE;
    }
-    /* Register the chip driver APIs with the platform driver. */
+    /* Register the device driver APIs with the platform driver. */
    if (PanelDataRegister(&g_panelData) != HDF_SUCCESS) {
        HDF_LOGE("%s: PanelDataRegister error!", __func__);
        return HDF_FAILURE;
@@ -346,4 +360,3 @@ struct HdfDriverEntry g_sampleDevEntry = {
 HDF_INIT(g_sampleDevEntry);
 ```
--- a/en/device-dev/driver/driver-peripherals-pinauth-des.md
+++ b/en/device-dev/driver/driver-peripherals-pinauth-des.md
-# Pin_auth
+# PIN Authentication
 ## Overview
 ### Function
-Personal Identification Number (PIN) authentication provides user authentication capabilities in identity authentication scenarios, such as device unlocking, payment, and app logins. After a user registers a PIN, the PIN authentication (Pin_auth) module unlocks the device only when a correct PIN is entered. The figure below shows the architecture of PIN authentication.
+Personal Identification Number (PIN) authentication provides user authentication capabilities in identity authentication scenarios, such as device unlocking, payment, and app logins. After a user registers a PIN, the PIN authentication (Pin_auth) module unlocks the device only when the correct PIN is entered. The figure below shows the architecture of PIN authentication.
 The Pin_auth driver is developed based on the Hardware Driver Foundation (HDF). The Pin_auth driver model shields hardware differences and provides stable PIN authentication capabilities for the user User_auth framework (User_auth) and PIN authentication system ability (SA). The PIN authentication capabilities include obtaining the PIN authentication executor list, executor information, and anti-brute force information of the specified template, comparing the template ID list of the executor and that of User_auth, enrolling or deleting PINs, and performing PIN authentication.
@@ -21,7 +21,7 @@ The identity authentication consists of User_auth and basic authentication servi
 - Executor security level
-  Certain security level is required for the execution environment of an executor. For example, the executor security level is low for an operation performed without access control and high for an operation performed in a Trusted Execution Environment (TEE).
+  Security level required for the execution environment of an executor.
 - Executor role
@@ -58,10 +58,10 @@ The Pin_auth driver provides basic PIN authentication capabilities for the upper
 **Figure 2** Pin_auth service and pin_auth driver APIs
-![image](figures/pin_auth_service_and_driver_interaction.png "interaction between the Pin_auth service and driver")
+![image](figures/pin_auth_service_and_driver_interaction.png "interaction between the pin_auth service and driver")
 ### Constraints
-PIN authentication must be implemented in a TEE, and the confidential information, such as PINs and credentials, must be stored in a TEE.
+PIN authentication must be implemented in a Trusted Execution Environment (TEE), and the confidential information, such as PINs and credentials, must be stored in a TEE.
 ## Development Guidelines
 ### When to Use
@@ -110,7 +110,7 @@ The following uses the RK3568 platform as an example to demonstrate how to devel
 The development procedure is as follows:
-1. Develop the Pin_auth driver based on the HDF. The **Bind()**, **Init()**, **Release()**, and **Dispatch()** functions are used. For details about the code, see [pin_auth_interface_driver.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/Pin_auth/hdi_service/src/pin_auth_interface_driver.cpp).
+1. Develop the Pin_auth driver based on the HDF. The **Bind()**, **Init()**, **Release()**, and **Dispatch()** functions are used. For details about the code, see [pin_auth_interface_driver.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/pin_auth/hdi_service/src/pin_auth_interface_driver.cpp).
   ```c++
   // Create the PinAuthInterfaceService object by using the custom HdfPinAuthInterfaceHost object, which consists of the IoService object and HDI service.

--- a/en/device-dev/driver/driver-peripherals-user-auth-des.md
+++ b/en/device-dev/driver/driver-peripherals-user-auth-des.md
-# User_auth
+# User Authentication
 ## Overview
@@ -6,7 +6,7 @@
 User authentication is indispensable in identity authentication scenarios, such as device unlocking, payment, and app logins. The user authentication framework (User_auth) manages the mappings between user identities and authentication credential templates in a unified manner. It schedules executors implemented by basic authentication services (including PIN authentication and facial recognition) to register user authentication credentials, delete credentials, obtain related information, and complete authentication. The figure below shows the architecture of user authentication.
-The User_auth driver is developed based on the Hardware Driver Foundation (HDF). It shields hardware differences and provides stable user authentication capabilities for apps and account management system ability (SA). It supports user credential management, authentication information enrollment, authentication scheme generation, and authentication executor information management.
+The User_auth driver is developed based on the Hardware Driver Foundation (HDF). It shields hardware differences and provides stable user authentication capabilities for apps and account management system ability (SA). It supports user credential management, authentication information enrollment, authentication scheme generation, and executor information management.
 **Figure 1** User authentication architecture
@@ -41,7 +41,7 @@ The identity authentication consists of the User_auth framework and basic authen
 - Executor security level
-  Certain security level is required for the execution environment of an executor. For example, the executor security level is low for an operation performed without access control and high for an operation performed in a Trusted Execution Environment (TEE).
+  Security level required for the execution environment of an executor.
 - User_auth public key & executor public key
@@ -66,11 +66,11 @@ The identity authentication consists of the User_auth framework and basic authen
 - SA
-  SAs are loaded by the System Ability Manager service to provide basic system capabilities for the OpenHarmony system.
+  SAs are loaded by the System Ability Manager to provide basic system capabilities for OpenHarmony devices.
 - Kit
-  The kit provides basic application programming interfaces (APIs) for third-party applications.
+  The kit provides basic APIs for third-party applications.
 - Inner API
@@ -78,22 +78,22 @@ The identity authentication consists of the User_auth framework and basic authen
 ### Working Principles
-The User_auth driver shields the differences of security devices and environments. It provides unified interface for the User_auth service to implement management of authentication executors and credentials as well as authentication scheme generation.
+The User_auth driver shields the differences of security devices and environments. It provides unified interfaces for the User_auth service to implement management of executors and credentials as well as authentication scheme generation.
 You can develop drivers to call Hardware Device Interface (HDI) APIs based on the HDF and the chip you use.
 **Figure 2** User_auth service and User_auth driver APIs
-![image](figures/user_auth_service_and_driver_api.png "interaction between the uin_auth service and driver")
+![image](figures/user_auth_service_and_driver_api.png "interaction between the user_auth service and driver")
 ### Constraints
-The User_auth driver must be implemented in a TEE to ensure secure storage of user credential information and trustworthiness of user authentication results.
+The User_auth driver must be implemented in a Trusted Execution Environment (TEE) to ensure secure storage of user credentials and trustworthiness of user authentication results.
 ## Development Guidelines
 ### When to Use
-The User_auth driver provides stable user credential management, authentication session management, and executor information management capabilities for the User_auth service to ensure successful PIN authentication and biometric recognition on devices.
+The User_auth driver provides stable user credential management, authentication session management, and executor information management for the User_auth service to ensure successful PIN authentication and biometric recognition on devices.
 ### Available APIs
@@ -106,7 +106,7 @@ The User_auth driver provides stable user credential management, authentication
 | DeleteExecutor(uint64_t index)                               | Deletes an executor.                             |
 | OpenSession(int32_t userId, std::vector<uint8_t>& challenge) | Opens a session for authentication credential management.                                   |
 | CloseSession(int32_t userId)                                 | Closes a session for authentication credential management.                                   |
-| BeginEnrollment(int32_t userId, const std::vector<uint8_t>& authToken, const EnrollParam& param,<br>        ScheduleInfo& info) | Enrolls the user authentication credential. If a user has enrolled a PIN, the new PIN enrolled will replace the old PIN.|
+| BeginEnrollment(int32_t userId, const std::vector<uint8_t>& authToken, const EnrollParam& param,<br>        ScheduleInfo& info) | Enrolls the user authentication credential. If a user has enrolled a PIN, the old PIN will be overwritten.|
 | UpdateEnrollmentResult(int32_t userId, const std::vector<uint8_t>& scheduleResult, uint64_t& credentialId,<br>        CredentialInfo& oldInfo) | Updates the data to complete this enrollment.                                |
 | CancelEnrollment(int32_t userId)                             | Cancels an enrollment operation.                                              |
 | DeleteCredential(int32_t userId, uint64_t credentialId, const std::vector<uint8_t>& authToken,<br>        CredentialInfo& info) | Deletes credential information based on the specified **credentialId**.                              |
@@ -119,13 +119,13 @@ The User_auth driver provides stable user credential management, authentication
 | CancelAuthentication(uint64_t contextId)                     | Cancels an authentication.                                              |
 | BeginIdentification(uint64_t contextId, AuthType authType, const std::vector<int8_t>& challenge,<br>        uint32_t executorId, ScheduleInfo& scheduleInfo) | Starts an identification to generate the identification scheme and scheduling information.                          |
 | UpdateIdentificationResult(uint64_t contextId, const std::vector<uint8_t>& scheduleResult,<br>        IdentifyResultInfo& info) | Updates the identification result to evaluate the identification scheme.                  |
-| CancelIdentification(uint64_t contextId)                     | Cancel an identification.                                              |
+| CancelIdentification(uint64_t contextId)                     | Cancels an identification.                                              |
 | GetAuthTrustLevel(int32_t userId, AuthType authType, uint32_t& authTrustLevel) | Obtains the authentication trust level of the specified authentication type.                      |
 | GetValidSolution(int32_t userId, const std::vector<AuthType>& authTypes, uint32_t authTrustLevel,<br>        std::vector<AuthType>& validTypes) | Obtains the valid authentication scheme based on the authentication trust level for a user.                  |
 ### How to Develop
-The following uses the Hi3516DV300 platform as an example to demonstrate how to develop the User_auth driver. <br/>The directory structure is as follows:
+The following uses the Hi3516D V300 development board as an example to demonstrate how to develop the User_auth driver. <br/>The directory structure is as follows:
 ```undefined
 // drivers/peripheral/user_auth
@@ -144,7 +144,7 @@ The development procedure is as follows:
 1. Develop the User_auth driver based on the HDF. The **Bind()**, **Init()**, **Release()**, and **Dispatch()** functions are used. For details about the code, see [user_auth_interface_driver.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/user_auth/hdi_service/service/user_auth_interface_driver.cpp).
   ```c++
-   // Create the IRemoteObject object by using the custom HdfUserAuthInterfaceHost object, which consists of the IoService object and HDI service.
+   // Create an IRemoteObject object by using the custom HdfUserAuthInterfaceHost object, which consists of the IoService object and HDI service.
   struct HdfUserAuthInterfaceHost {
       struct IDeviceIoService ioService;
       OHOS::sptr<OHOS::IRemoteObject> stub;
@@ -197,7 +197,7 @@ The development procedure is as follows:
       auto serviceImpl = IUserAuthInterface::Get(true);
       if (serviceImpl == nullptr) {
-           HDF_LOGE("%{public}s: failed to get of implement service", __func__);
+           HDF_LOGE("%{public}s: Failed to obtain service", __func__);
           return HDF_FAILURE;
       }
@@ -310,18 +310,18 @@ The development procedure is as follows:
       CoAuthSchedule scheduleInfo;
       int32_t ret = CheckEnrollPermission(checkParam, &scheduleInfo.scheduleId);
       if (ret != RESULT_SUCCESS) {
-           IAM_LOGE("check permission failed");
+           IAM_LOGE("Permission check failed");
           GlobalUnLock();
           return ret;
       }
       ret = GetCoAuthSchedule(&scheduleInfo);
       if (ret != RESULT_SUCCESS) {
-           IAM_LOGE("get schedule info failed");
+           IAM_LOGE("Failed to get schedule info");
           GlobalUnLock();
           return ret;
       }
       if (!CopyScheduleInfo(&scheduleInfo, &info)) {
-           IAM_LOGE("copy schedule info failed");
+           IAM_LOGE("Failed to copy schedule info");
           ret = RESULT_BAD_COPY;
       }
       GlobalUnLock();
@@ -456,7 +456,7 @@ The development procedure is as follows:
       UserAuthTokenHal authTokenHal;
       info.result = RequestAuthResultFunc(contextId, scheduleResultBuffer, &authTokenHal);
       if (info.result != RESULT_SUCCESS) {
-           IAM_LOGE("execute func failed");
+           IAM_LOGE("Failed to execute the function");
           DestoryBuffer(scheduleResultBuffer);
           GlobalUnLock();
           return info.result;
@@ -481,7 +481,7 @@ The development procedure is as follows:
       uint32_t scheduleIdNum = 0;
       int32_t ret = CancelContextFunc(contextId, nullptr, &scheduleIdNum);
       if (ret != RESULT_SUCCESS) {
-           IAM_LOGE("execute func failed");
+           IAM_LOGE("Failed to execute the function");
           GlobalUnLock();
           return ret;
       }
@@ -492,7 +492,7 @@ The development procedure is as follows:
 ### Verification
-Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516DV300 platform. The sample code for verifying the authentication and authentication cancellation is as follows:
+Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516D V300 development board. The sample code for verifying and canceling the authentication is as follows:
 ```js
 // API version 8
@@ -549,9 +549,9 @@ export default {
        });
        let cancelCode = this.auth.cancel(contextId);
        if (cancelCode == userIAM_userAuth.Result.SUCCESS) {
-            console.info("cancel auth success");
+            console.info("Authentication canceled successfully");
        } else {
-            console.error("cancel auth fail");
+            console.error("Failed to cancel authentication");
        }
    }
 }

--- a/en/device-dev/driver/figures/architecture-of-the-display-driver-model.png
+++ b/en/device-dev/driver/figures/architecture-of-the-display-driver-model.png
--- a/en/device-dev/driver/figures/mipi-dsi.png
+++ b/en/device-dev/driver/figures/mipi-dsi.png
--- a/en/device-dev/driver/figures/ttl-interface.png
+++ b/en/device-dev/driver/figures/ttl-interface.png