Otg dual-role cooperative linkage method and apparatus, device, and medium

Abstract

The application discloses an OTG double-role cooperative linkage method and device, equipment and medium, and the OTG double-role cooperative linkage method is applied to an embedded device containing a Type-C interface and a controller. The method perceives connection changes by listening to kernel events and CC pin states, reads initial information and updates configurations when connected, determines target data and a power role in combination with the double-role capability of a peer end and user preferences, issues a switching request to the controller when conditions are met and reads back for verification, identifies external devices according to kernel driver information after verification is successful, automatically triggers business services and synchronously configures according to a preset mapping, and cleans up configurations and stops services when disconnected. The method realizes unified control of roles, automatic linkage of external device identification and business, and real-time synchronization of software and hardware states, effectively solves the fragmentation problem of multi-role cooperative management, and significantly improves the plug-and-play experience and system response efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer interface management and control technology, and in particular to an OTG dual-role collaborative linkage method, device, equipment and medium. Background Technology

[0002] With the widespread adoption of USB Type-C and USB OTG (On-The-Go) technologies, embedded devices such as portable wireless routers and mobile gateways commonly use Type-C interfaces to achieve multiple functions including charging, data communication, peripheral expansion, and reverse power supply. In existing embedded systems, the management of the USB OTG interface typically relies on independent collaboration between the underlying hardware controller and the operating system kernel driver. Specifically, the switching of the USB data role (Host / Device) is mostly handled by the USB controller or Gadget / Host driver stack, while the negotiation and control of the power role (Source / Sink) is handled by a separate Type-C / PD power management chip. Upper-layer business systems often only obtain fixed default role states, lacking a unified scheduling interface for data and power roles.

[0003] However, the existing architecture described above has significant drawbacks in practical applications. First, the control logic for the data role and the power role is independent and fragmented, making it difficult for the system to dynamically and collaboratively switch between Host / Device and Source / Sink combinations based on the access scenario. This leads to rigid role negotiation when dual-role devices are connected, which can easily conflict with the user's actual usage intentions. Second, peripheral type identification and upper-layer service startup are severely disconnected. Traditional solutions only treat USB plugging and unplugging as underlying driver loading events, failing to establish an automatic mapping and event distribution mechanism between driver identifiers and router services (such as mobile network sharing, USB network card expansion, and NAS storage mounting). Service triggering often relies on manual user configuration or fragmented independent scripts, disrupting the smoothness of plug-and-play functionality. Furthermore, there is a lack of a reliable closed-loop synchronization mechanism between the user interface, system configuration files, kernel driver nodes, and the underlying hardware state. If the user modifies the configuration in the interface but fails to align with the sysfs node and PD negotiation state in real time, inconsistencies between the interface display, software configuration, and the actual hardware role are highly likely to occur. At the same time, some systems use high-frequency polling to detect connection status, which not only increases the CPU overhead of embedded devices but also leads to status response delays and event loss.

[0004] In summary, existing embedded devices suffer from fragmented control over USB OTG data and power roles, disconnected peripheral identification and service linkage, and asynchronous hardware and software states. These issues ultimately lead to fragmented multi-role collaborative management and a poor plug-and-play experience. Therefore, there is an urgent need for an OTG management method that can uniformly manage role negotiation, automatically link service functions, and maintain end-to-end state synchronization. Summary of the Invention

[0005] The embodiments of the present invention provide an OTG dual-role collaborative linkage method, apparatus, device and medium, which aims to solve the technical problems of fragmented multi-role collaborative management and poor plug-and-play experience caused by the dispersed control of USB OTG data and power roles, the disconnect between peripheral identification and service linkage, and the asynchrony of software and hardware states in existing embedded devices.

[0006] In a first aspect, embodiments of the present invention provide an OTG dual-role collaborative linkage method, wherein the embedded device includes at least one USB Type-C interface supporting OTG function and a Type-C controller managing the USB Type-C interface, the method comprising: listening to connection status events of the USB Type-C interface, the connection status events including kernel device events and status events generated based on changes in the connection pin status of the Type-C controller; and determining the connection status of the USB Type-C interface based on the connection status events; when the connection status events determine the connection status of the USB Type-C interface... When the Type-C interface changes from an unconnected state to a connected state, the system reads the initial connection information reported by the Type-C controller and updates the connection status of the corresponding interface in the configuration system. The initial connection information includes the connection pin status, dual-role capability identifier, and the current data role and current power role. Based on the dual-role capability identifier, the system determines the role capability type of the peer device and, based on the role capability type and user role preferences in the configuration system, determines the target data role and target power role. When preset switching conditions are met, the target data role and target power role are written as a role switching request to the Type-C controller's driver interface, and switching verification is performed through readback and event confirmation after writing. When the switching verification is successful and the kernel device event is triggered, the system identifies the peripheral type based on the driver information in the kernel device event, triggers the corresponding service based on the preset driver-service mapping relationship, and synchronously updates the role status in the configuration system. When the connection status event determines that the USB Type-C interface changes from a connected state to an unconnected state, the system clears the device information and status items of the corresponding interface in the configuration system and stops or refreshes the started service.

[0007] Secondly, embodiments of the present invention also provide an OTG dual-role collaborative linkage device for executing the OTG dual-role collaborative linkage method as described above.

[0008] Thirdly, embodiments of the present invention also provide a computer device, the computer device including a memory and a processor connected to the memory; the memory is used to store a computer program; the processor is used to run the computer program stored in the memory to execute the steps of the above-described OTG dual-role collaborative linkage method.

[0009] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, can implement the steps of the above-described OTG dual-role collaborative linkage method.

[0010] Compared with the prior art, the beneficial effects of the present invention are: In the technical solution of this invention, the OTG dual-role collaborative linkage method is applied to embedded devices containing Type-C interfaces and controllers. This method senses connection changes by monitoring kernel events and CC pin status; upon connection, it reads initial information and updates the configuration, determining the target data and power roles based on the dual-role capabilities of the peer and user preferences; when conditions are met, it sends a switching request to the controller and performs verification; after successful verification, it identifies peripherals based on kernel driver information, automatically triggers service functions according to preset mappings, and synchronizes configurations; upon disconnection, it clears the configuration and stops the service. This method achieves unified role management, peripheral identification, automatic service linkage, and real-time synchronization of hardware and software status, effectively solving the fragmentation problem of multi-role collaborative management and significantly improving the plug-and-play experience and system response efficiency. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 2 This is the first sub-flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 3 This is the second sub-flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 4 This is the third sub-flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 5 This is the fourth sub-flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 6 This is the fifth sub-flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 7 This is the sixth sub-flowchart of the OTG dual-role collaborative linkage method provided by the present invention; Figure 8A schematic block diagram of a unit of the OTG dual-role collaborative linkage device provided by the present invention; Figure 9 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0015] It should also be understood that the terminology used in this specification is for the purpose of describing embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0016] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0017] This invention addresses the technical problems of fragmented multi-role collaborative management and poor plug-and-play experience caused by dispersed control of USB OTG data and power roles, disconnect between peripheral identification and service linkage, and asynchronous hardware and software states in existing embedded devices. It discloses an OTG dual-role collaborative linkage method. This method is applied to embedded devices, which include at least one USB Type-C interface supporting OTG functionality and a Type-C controller managing the USB Type-C interface.

[0018] Specifically, embedded devices can be portable 4G / 5G wireless routers, MiFi portable WiFi devices, mobile gateways, travel routers based on the OpenWrt platform, or in-vehicle routers, outdoor customer terminal devices, emergency communication terminals, or embedded Linux devices with USB OTG functionality such as industrial gateways, edge computing nodes, and IoT gateways.

[0019] In terms of hardware interface and controller topology, the embedded device includes at least one USB Type-C interface supporting OTG functionality and a Type-C controller managing the USB Type-C interface. In a typical dual-port hardware topology embodiment, the embedded device is equipped with a first Type-C interface and a second Type-C interface. The first Type-C interface serves as a combined data and power port and is managed by the first Type-C controller; the second Type-C interface serves as an independent power port and is managed by the second Type-C controller. Specifically, the first and second Type-C controllers can employ the AW35615 PD control chip. The first and second Type-C controllers communicate with the embedded device's main CPU via an I2C bus. The first and second Type-C controllers expose driver interfaces to the embedded device's operating system for reading and controlling hardware status. These driver interfaces are specifically sysfs driver nodes under the Linux system, including data role nodes, power role nodes, dual-role capability nodes, and connection pin nodes.

[0020] In terms of power management and hardware path control, embedded devices also include a charging management subsystem and hardware path control components. The charging management subsystem includes a main charging chip, a charge pump auxiliary charging chip, and a fuel gauge, such as the SGM41542 main charging chip, the SGM41600 charge pump auxiliary charging chip, and the CW2217 fuel gauge, used to collaboratively manage the battery charging and discharging strategy of the embedded device. The hardware path control components include a BOOST boost circuit, MOSFET path switches, and an OVP overvoltage protection circuit. When the embedded device needs external power, the OTG management service configures the power supply role as a Source at the software layer and enables the BOOST boost circuit and turns on the corresponding MOSFET path switch at the hardware layer. When the embedded device receives external charging, the software layer configures the power supply role as a Sink, and the charging management subsystem takes over the charging path. The OVP overvoltage protection circuit provides hardware-level safety protection when overvoltage or power path conflicts are detected.

[0021] In terms of software system architecture, the embedded device runs an embedded Linux operating system based on OpenWrt and has the software infrastructure to support the OTG dual-role collaborative linkage method. The embedded device includes a configuration system, specifically a UCI configuration system, used to persistently store user role preferences, interface connection status, and device lists. The embedded device has a kernel device event mechanism, specifically through the Hotplug mechanism or the uevent listening mechanism based on NETLINK_KOBJECT_UEVENT, used to capture kernel device events such as adding, binding, removing, unbinding, and restarting USB devices. The embedded device also includes an inter-process call bus, specifically an RPC / ubus service interface, used for cross-process communication between the OTG management service and upper-layer business services such as network sharing, network port expansion, and NAS storage, as well as between the OTG management service and the user interface. In addition, the embedded device provides a user interface, including a web management interface, device screen pop-up components, and command-line tools, used to display USB status to the user and receive user role selection commands.

[0022] Reference Figures 1 to 7 The OTG dual-role collaborative linkage method includes the following steps: S110. Listen to the connection status events of the USB Type-C interface, the connection status events including kernel device events and status events generated based on the connection pin status changes of the Type-C controller; S120. When the USB Type-C interface changes from an unconnected state to a connected state based on the connection state event, the initial connection information reported by the Type-C controller is read and the connection state of the corresponding interface in the configuration system is updated. The initial connection information includes the connection pin state, dual-role capability identifier, and the current data role and current power role. S130. Determine the role capability type of the peer device based on the dual role capability identifier, and determine the target data role and target power role based on the role capability type and the user role preference in the configuration system. S140. When the preset switching conditions are met, the target data role and the target power role are written as role switching requests to the driver interface of the Type-C controller, and the switching is verified by readback and event confirmation after writing. S150. When the switching verification is successful and the kernel device event is triggered, the peripheral type is identified according to the driver information in the kernel device event, the corresponding business service is triggered based on the preset driver-business mapping relationship, and the role status in the configuration system is updated synchronously. S160. When the USB Type-C interface changes from a connected state to a disconnected state based on the connection status event, the device information and status items of the corresponding interface in the configuration system are cleared, and the started service is stopped or refreshed.

[0023] Embedded devices typically run embedded Linux or OpenWrt operating systems. The Type-C controller communicates with the host processor via the I2C bus and exposes system file interface nodes to the operating system. At the beginning of the method execution, the system continuously listens for connection status events of the USB Type-C interface. A dual-path acquisition mechanism is used for these events: the primary path listens for device addition, binding, removal, unbinding, or restart events reported by the USB subsystem or network subsystem through the operating system's kernel device event mechanism; the secondary path reads the connection pin status nodes of the Type-C controller at one-second intervals through a status monitoring process to obtain changes in the physical level of the connection pins. This dual-path listening mechanism ensures accurate capture of USB Type-C interface insertion / removal status changes even in abnormal scenarios such as the Type-C controller not actively reporting events, system sleep / wake-up, or event loss, providing reliable trigger signals for the main process.

[0024] When the USB Type-C interface changes from an unconnected state to a connected state based on the connection status event, the OTG event management process immediately reads the initial connection information reported by the Type-C controller and updates the connection status of the corresponding interface in the configuration system to "connected". The initial connection information includes the connection pin status, dual-role capability identifier, and the current data role and current power role. This information is obtained by reading the system file nodes exposed by the Type-C controller driver. Subsequently, the system determines the role capability type of the peer device based on the dual-role capability identifier. If the dual-role capability identifier indicates that the peer device supports dual-role switching, the system further queries the user role preferences stored in the configuration system, including historical data role selection, historical power role selection, and prompt flags. If the prompt flag is enabled and there is no remembered user role selection in the configuration system, the system triggers a role selection prompt through the user interaction interface. After user confirmation, the selection result is saved to the configuration system. If user role preferences already exist in the configuration system, the saved data role and power role are directly extracted as the target data role and target power role. If the dual-role capability identifier indicates that the peer device is a single-role device, the system will automatically deduce the target data role and the target power role based on the default capabilities of the single-role device, thereby taking into account both automated processing and user-defined needs.

[0025] After determining the target data role and target power role, the system enters the controlled role switching phase. When preset switching conditions are met, the OTG event management process encapsulates the target data role and target power role into a role switching request and writes it to the control node corresponding to the Type-C controller's driver interface. The preset switching conditions require that the Type-C controller's current power protocol negotiation process has ended and the connection pin state remains stable. If the Type-C controller is detected to be in protocol negotiation or the connection pin level is fluctuating, the system automatically delays the write operation until the state stabilizes. After the role switching request is written, the system executes a switching verification process: first, it reads back the actual values ​​of the data role node and power role node through the driver interface to confirm that the written value matches the target value; second, it listens for kernel device events to determine if a corresponding device binding or enumeration completion event has been generated; finally, it performs a secondary confirmation based on the peripheral enumeration results. The switching verification is considered successful only when the readback value matches and both the kernel device event and the enumeration results indicate successful role switching. If the verification times out or the Type-C controller returns a rejection signal, the system automatically reverts to the role before the switch or the default safe role and records the abnormal state to prevent forced switching from triggering hardware protection or causing link interruption.

[0026] Once the switchover verification is successful and a kernel device event is triggered, the system enters the peripheral identification and service linkage phase. The OTG event management process extracts the driver name, subsystem identifier, interface information, or device vendor identifier and product identifier from the kernel device event and matches them against a preset driver-service mapping table. Upon successful matching, the system sends a start command to the corresponding service module via the inter-process call bus. For example, it maps network sharing drivers to network sharing services, storage drivers to network attached storage services, and network interface card extension drivers to wired network extension services. Simultaneously with the service startup, the system synchronously writes the current target data role, target power role, and connection status into the configuration system, ensuring complete consistency between the user management interface display, configuration file records, and the actual hardware status of the Type-C controller. When the USB Type-C interface changes from a connected state to a disconnected state based on the connection status event, the system immediately clears the device list and status item of the corresponding interface in the configuration system, sends a stop or refresh command to the started service, releases system resources, and restores the USB Type-C interface to a safe standby state, completing full lifecycle management.

[0027] In one embodiment, step S110 includes: S111. Register a listener for device addition, binding, removal, unbinding, and restart events corresponding to the USB Type-C interface through the kernel device event mechanism; S112. Read the connection pin node of the Type-C controller at a preset period to obtain the connection pin status; S113. When a change in the state of the connection pin is detected, the state update of the configuration system and the subsequent role determination and switching process are triggered.

[0028] In the operating system environment of embedded devices, the kernel device event mechanism serves as the primary path for connection state awareness. It registers and listens for underlying hardware events corresponding to the USB Type-C interface via Netlink sockets or the Hotplug script framework. Specifically, the system configures uevent listening rules in the kernel space to capture in real-time device add, device bind, device remove, device unbind, and device reboot events reported by the USB subsystem and the Type-C controller driver. When an external device is plugged into the USB Type-C interface and a physical layer handshake is completed, the kernel driver stack triggers the device add and device bind events sequentially. When the external device is unplugged or the link is abnormally disconnected, the kernel driver stack reports the device remove and device unbind events. When the Type-C controller needs to be reinitialized due to protocol reset or driver reload, the kernel driver stack reports the device reboot event. By parsing the action identifiers and device paths in the aforementioned kernel device events, the system can respond to logical state changes of the USB Type-C interface in milliseconds, providing immediate trigger signals for subsequent role negotiation and business interaction.

[0029] To compensate for the blind spots in state awareness of a single event-driven mechanism in scenarios such as system sleep / wake-up, kernel event loss, or failure of the Type-C controller to actively report, this embodiment introduces a connection pin status polling mechanism based on a preset period as an auxiliary verification path. The state monitoring process runs continuously in the background, reading the connection pin nodes exposed by the Type-C controller at a fixed interval of one second. The connection pin nodes correspond to the CC pin level status in the Type-C protocol, directly reflecting whether the physical link is connected. The state monitoring process obtains the current level value of the connection pin node through the system file reading interface and compares it with the connection pin status cached in the previous cycle. If the two level values ​​are consistent, it is determined that the physical connection status of the USB Type-C interface has not changed, and the state monitoring process continues to maintain the preset periodic polling cycle; if it detects that the connection pin status has jumped from disconnected to connected, or from connected to disconnected, it is determined that the physical connection status has substantially changed.

[0030] When the status monitoring process detects a change in the connection pin status, it immediately triggers the status update of the configuration system and the subsequent role determination and switching process. Specifically, the status monitoring process first writes the latest connection pin status into the status field of the corresponding USB Type-C interface in the configuration system, ensuring that the system configuration file and the underlying physical link status remain synchronized. Subsequently, the status monitoring process wakes up the OTG event management process through an inter-process communication interface or semaphore mechanism, passing the connection pin status change identifier as a trigger parameter. Upon receiving the trigger parameter, the OTG event management process immediately initiates the connection status determination logic. If the connection pin status indicates a connection, the OTG event management process reads the initial connection information reported by the Type-C controller and enters the role determination process; if the connection pin status indicates a disconnection, the OTG event management process directly executes the configuration cleanup and service termination process. By combining the real-time response of the kernel device event mechanism with the fallback verification of periodic polling of the connection pin node, this embodiment constructs a highly reliable dual-path status monitoring architecture, effectively avoiding interface status misjudgments caused by event loss or driver delay, and ensuring the stability and continuity of the OTG dual-role collaborative linkage method in complex operating environments.

[0031] In one embodiment, step S120 includes: S121. Read the connection pin nodes of the Type-C controller to obtain the physical connection status of the USB Type-C interface; S122. Read the dual-role capability node of the Type-C controller and obtain the dual-role capability identifier of the peer device; S123. Read the data role and power role currently reported by the Type-C controller, and use them as the current data role and the current power role; S124. For dual-role devices that have not yet completed USB enumeration, enter the negotiation state according to the connection pin status and the dual-role capability identifier; S125. After the device role in the pending negotiation state stabilizes and the kernel device event is generated, the subsequent peripheral type identification is then performed.

[0032] When the OTG event management process determines that the USB Type-C interface has changed from an unconnected state to a connected state based on the connection status event, the OTG event management process first accesses the connection pin node exposed by the Type-C controller through the system file reading interface provided by the operating system to obtain the physical connection status of the USB Type-C interface and confirm that the physical link has been established.

[0033] Subsequently, the OTG event management process reads the dual-role capability node of the Type-C controller to obtain the dual-role capability identifier of the peer device. The dual-role capability identifier is used to indicate whether the peer device supports dynamic switching between data role and power role.

[0034] Simultaneously, the OTG event management process reads the data role and power role currently reported by the Type-C controller, and records the read role values ​​as the current data role and current power role, serving as the initial benchmark for subsequent role negotiation. After the read operation is completed, the OTG event management process writes the physical connection status, dual-role capability identifier, current data role, and current power role into the status field of the corresponding USB Type-C interface in the configuration system, completing the initialization update of the configuration system.

[0035] For dual-role devices that have not yet completed USB enumeration, this embodiment employs a delayed identification and state machine management mechanism. Since dual-role devices need to undergo power delivery protocol negotiation, role flipping, and USB bus enumeration processes after the physical connection is established, the operating system kernel has not yet loaded the corresponding device driver at this time and cannot directly obtain the driver name or interface information.

[0036] Therefore, the OTG event management process switches the USB Type-C interface processing flow to the pending negotiation state based on the connection level indicated by the connection pin status and the dual-role capability identifier indicating support for dual-role features. In the pending negotiation state, the OTG event management process suspends the peripheral type identification logic based on driver information and instead continuously monitors the negotiation progress flag and connection pin status changes of the Type-C controller to avoid identification errors or service mis-triggering due to premature reading of unstable driver nodes.

[0037] Once the peer device in the pending negotiation state completes the underlying protocol handshake and its role is stable, the Type-C controller reports a role switch completion signal to the operating system kernel and triggers a device addition or device binding event in the kernel device event mechanism. After the OTG event management process captures the kernel device event through the kernel event listening mechanism, it determines that the pending negotiation state has ended and the device role has been stable.

[0038] At this point, the OTG event management process exits the pending negotiation state and formally executes the subsequent peripheral type identification process. By reading the subsystem identifier, driver name, interface descriptor, or device vendor identifier and product identifier carried in the kernel device event, the OTG event management process can accurately determine the specific type of the peer device and enter the target data role and target power role determination stage.

[0039] In one embodiment, step S130 includes: S131. When the dual-role capability identifier indicates that the peer device is a dual-role device, read the data role configuration, power role configuration and prompt flag of the corresponding interface in the configuration system. S132. If the prompt flag is enabled and there is no saved user role selection in the configuration system, then prompt the user to select a combination of target data role and target power role through the user interaction interface, and save the selected role combination to the configuration system according to the user's wishes after the user makes the selection. S133. If there are saved user role selections in the configuration system, the saved data role and power role are directly applied as the target data role and the target power role. S134. When the dual-role capability identifier indicates that the peer device is a single-role device, the target data role and the target power role are automatically determined based on the capabilities of the single-role device.

[0040] When the OTG event management process determines that the peer device is a dual-role device based on the dual-role capability identifier, it accesses the independent configuration segment of the corresponding USB Type-C interface through the configuration system read interface to extract the data role configuration, power role configuration, and prompt flag. The configuration system uses structured key-value pairs to store user preferences. The prompt flag is used to control whether the system initiates a role selection interaction with the user when a dual-role device is connected. The data role configuration and power role configuration respectively record the host or slave mode and power supply or receiving mode combination confirmed by the user in historical connection scenarios. While reading the configuration information, the OTG event management process verifies whether there are any saved user role selection records in the configuration system, providing a basis for subsequent policy branching.

[0041] If the read prompt flag is in an enabled state, and there is no saved user role selection record in the configuration system, the OTG event management process sends a role selection request to the user interaction layer via the inter-process call bus. The user interaction layer adapts the interaction method according to the hardware form of the embedded device: in devices equipped with a display screen, a local screen pop-up is triggered by calling the screen control interface, and the pop-up interface provides a combination matrix of data role options and power role options; in devices that only support network management, status notifications are pushed through the web management interface or the user is redirected to the OTG configuration page. After the user completes the combination selection and confirmation of the target data role and target power role in the interaction interface, the OTG event management process receives the user's selection result, writes the selected data role value and power role value into the user role selection field of the configuration system, and updates the persistent state of the prompt flag according to the user's selected memory options. The role selection and saving process ensures that when a dual-role device is first connected, the user can flexibly specify the role combination according to the actual usage intention and persist the decision result to non-volatile storage.

[0042] If a user role selection record already exists in the configuration system, the OTG event management process skips the interactive prompts and directly extracts the saved data role and power role from the configuration system, using them as the target data role and target power role. In this scenario, the system compares the vendor identifier, product identifier, or driver characteristics of the currently connected device with the device profile in the historical configuration record. If the matching degree meets a preset threshold, it is determined to be a similar device or a similar usage scenario, and the historical role policy is directly reused. The configuration reuse mechanism effectively avoids the interference of repeated pop-ups on user operations, achieving an automated experience where a single configuration takes effect long-term, while retaining the permission to manually overwrite historical configurations through the user interaction interface, ensuring the flexibility of policy adjustments.

[0043] When the dual-role capability identifier indicates that the peer device is a single-role device, the OTG event management process automatically determines the target data role and target power role based on the inherent hardware capabilities of the single-role device. In practice, the OTG event management process queries the preset single-role device capability mapping rule base. If the peer device is a storage device or network extension device that only supports a fixed host data role, the system automatically matches the target data role to slave mode to maintain data path compatibility, and matches the target power role to power supply mode according to the device's power supply specifications. If the peer device is a dedicated debugging terminal or powered peripheral that only supports a fixed slave data role, the system automatically matches the target data role to host mode, and matches the target power role to powered mode or on-demand power supply mode. The automatic determination process is entirely executed by the system backend based on hardware protocol specifications, requiring no user intervention, ensuring that a role combination conforming to electrical characteristics and data link specifications can be quickly established when a single-role peripheral is connected.

[0044] Furthermore, during the process of the embedded device automatically determining the target role and attempting to apply these roles for underlying hardware switching, switching failures may occur due to unstable hardware status, lack of support for the requested role by the peer device, or poor physical connection. In practice, the embedded device continuously monitors the role switching execution results. If the switching verification fails within a preset time, the role is rejected by the Type-C controller, the protocol handshake fails, or the link is disconnected, the embedded device immediately aborts the current switching attempt and reverts the data and power roles of the Type-C controller to their previous roles or preset safety roles. The preset time can be reasonably set based on the system response speed and the typical time consumption for PD protocol negotiation. The preset safety role can specifically be a high-impedance state with no external power supply and the data channel closed, or a combination of the system's default Device data role and Sink power role, thereby effectively preventing hardware damage, power short circuits, or system crashes caused by role conflicts.

[0045] During or after the role rollback operation, the embedded device updates the abnormal status identifier in the configuration system. Specifically, the embedded device writes a specific abnormal status identifier for the currently malfunctioning USB Type-C interface in the configuration system, such as updating the corresponding interface's status configuration item to an error or failure status. By updating the abnormal status identifier, the upper-layer management interface, status monitoring module, and other business services can accurately perceive that the current interface is in an abnormal state, thereby preventing the system from continuing to execute subsequent peripheral identification and business linkage logic based on incorrect or incomplete hardware switching states, and preventing deeper system-level errors from occurring.

[0046] After updating the abnormal status flags in the configuration system, the embedded device, based on the specific abnormal type and the preset system recovery strategy, will either re-trigger the user selection prompt or wait for the next connection status event. Specifically, if the abnormality is due to a failed protocol handshake or a rejected role, but the physical link remains connected, the embedded device will re-trigger the user selection prompt through the user interface, displaying the information that the automatic handover failed and allowing the user to manually intervene, forcibly specifying the target data role and target power role to attempt to establish a connection. If the abnormality is due to a broken link or extremely unstable connection pin status, indicating that the physical connection has failed, the embedded device will abandon the current retry mechanism, clear the relevant temporary status data, and wait for the next connection status event—that is, wait for the user to re-plug the device or replace the connection cable—before re-executing the initial connection information reading and role determination process.

[0047] In one embodiment, step S140 includes: S141. Before writing the role switching request, read the current role, connection status and negotiation status of the Type-C controller; S142. If the Type-C controller is in the process of protocol negotiation or the connection pin state is unstable, then delay writing and wait for the state to stabilize. S143. When the switching conditions are met, the target data role is written into the data role node of the Type-C controller, and the target power role is written into the power role node of the Type-C controller. S144. After the write operation, a second confirmation is performed through the node readback of the driver interface, the kernel device event, and the peripheral enumeration result. If the confirmation is successful, the switch verification is deemed to have passed.

[0048] Before the OTG event management process issues a role switching command, the system first performs a pre-processing status verification procedure. The OTG event management process accesses the current role node, connection status node, and negotiation status node exposed by the Type-C controller through the system file read interface provided by the operating system. This allows it to obtain the Type-C controller's current actual data role, actual power role, physical connection pin level status, and power delivery protocol negotiation progress flag. If the read negotiation status node indicates that the Type-C controller is in the process of power delivery protocol negotiation, or if the connection status node shows that the connection pin level is fluctuating or not locked to a stable threshold, then the safe switching conditions are not met. At this time, the OTG event management process does not perform a forced write operation but enters a delayed waiting state. It continuously polls the negotiation status node and connection status node through a status monitoring loop until the protocol negotiation completion flag is set and the connection pin level remains stable, ensuring that the underlying hardware link has the physical and protocol foundation to receive the new role command.

[0049] Once the Type-C controller is confirmed to be in an idle or stable state and the preset switching conditions are met, the OTG event management process encapsulates the target data role and target power role into a role switching request and writes it to the Type-C controller's driver interface. In practice, the OTG event management process writes the control value corresponding to the target data role to the data role node of the Type-C controller and the control value corresponding to the target power role to the power role node of the Type-C controller through the system file write interface. It should be noted that this write operation is defined as a role switching request issued by the upper-layer software to the lower-layer controller, rather than a direct hardware register overwrite bypassing the controller's internal state machine. After receiving the role switching request, the Type-C controller, in conjunction with its internal power management logic, overvoltage and overcurrent protection status, and external device response capabilities, autonomously executes the protocol handshake and role inversion process, thereby avoiding power delivery protocol conflicts, VBUS voltage fluctuations, or false triggering of hardware protection circuits caused by direct intervention from user-space processes.

[0050] After the role switch request is written, the system immediately initiates a multi-dimensional switch verification process to confirm the actual execution result of the role switch. The OTG event management process first reads the current values ​​of the data role node and the power role node again through the node readback mechanism of the driver interface, comparing whether the readback values ​​are completely consistent with the written target data role and target power role. If the node readback values ​​match, the system further monitors the kernel device event mechanism, capturing the role switch completion event, device rebinding event, or bus reset event reported by the Type-C controller or USB subsystem. At the same time, the system performs cross-validation based on the peripheral enumeration results, checking whether the operating system kernel has successfully loaded the device driver for the corresponding target role and generated the correct network interface node or storage device node. Only when the node readback values ​​are consistent, the kernel device event is triggered, and the peripheral enumeration results meet expectations, the system determines that the switch verification is successful and allows entry into the subsequent business service triggering stage. If any verification dimension fails or fails to respond within a timeout period, the system will record the verification failure status to provide a basis for decision-making in the subsequent exception handling process.

[0051] In one embodiment, step S150 includes: S151. Extract the driver name, subsystem identifier, interface information, device name or supplier identifier and product identifier from the kernel device events; S152. Match the extracted information in the driver-business mapping relationship; S153. Call the matched business service through the inter-process call interface to trigger the corresponding business event.

[0052] Once the handover verification is successful and the kernel device event mechanism reports the device binding or addition event, the OTG event management process immediately parses the underlying attribute fields carried by the kernel device event. Specifically, the OTG event management process extracts key characteristic data such as driver name, subsystem identifier, interface information, device name, and vendor and product identifiers by parsing the uevent message body or reading the attribute file in the sysfs device directory. The driver name reflects the specific driver module loaded by the operating system kernel for the peer device, the subsystem identifier indicates the hardware bus category to which the device belongs, the interface information describes the device's communication protocol type, the device name provides the logical node identifier assigned by the kernel, and the vendor and product identifiers provide a unique combination of codes from the hardware manufacturer. These characteristic data together constitute a multi-dimensional identification fingerprint of the peripheral type, providing accurate data input for subsequent business matching.

[0053] After acquiring multi-dimensional identification feature data, the OTG event management process matches the extracted information against the preset driver and service mapping relationships item by item. The driver and service mapping relationships are stored in the configuration system in the form of a structured configuration table or rule base, pre-defining the correspondence logic between the underlying driver identifier and the upper-layer router service type. During the matching process, the OTG event management process prioritizes comparing the driver name with the interface information. If the driver name matches a network sharing driver identifier, the peripheral type is determined to be a mobile network sharing device; if the driver name matches a wired network card driver identifier, it is determined to be a USB network extension device; if the driver name matches a mass storage driver identifier, it is determined to be a USB storage device; if the driver name matches a virtual network card driver identifier, it is determined to be a reverse network sharing device. When the driver name cannot be directly matched, the OTG event management process further combines the vendor identifier and product identifier to perform device profiling comparison, identifies peripherals of specific brands or models through the historical configuration database, and dynamically loads the corresponding service mapping rules. The matching mechanism ensures that the system can accurately transform the underlying USB plug-in / plug-out hardware events into router function events with clear business semantics.

[0054] After peripheral type matching is completed, the OTG event management process sends a start command to the matched service module through the inter-process call interface, triggering the corresponding service event. In practice, the inter-process call interface uses the ubus remote procedure call bus or a similar inter-process communication mechanism. The OTG event management process constructs a call request containing the service type identifier, interface name, and configuration parameters based on the matching result and sends it to the corresponding service daemon process. For example, when a network sharing service is matched, the system calls the network sharing service interface to trigger a network sharing event, automatically configuring network address translation rules and firewall policies; when a network extension service is matched, the system calls the wired network extension service interface to trigger a network port extension event, bridging the USB virtual network card to the LAN interface; when a storage service is matched, the system calls the network attached storage service interface to trigger a storage mount event, automatically performing file system identification, disk mounting, and shared directory publishing. After receiving the call request, the service module independently executes the corresponding service initialization process and feeds back the execution result to the OTG event management process through the inter-process call interface, achieving a closed loop between service triggering and status feedback.

[0055] Furthermore, the steps in S150 also include: S154. After the role switch is completed, the current data role, power role and connection status are written into the configuration system so that the management interface display status, configuration file status and the hardware role status of the Type-C controller are consistent. S155. When a role configuration modification request is received through the user interaction interface, the modified configuration is written into the configuration system and the OTG management service is restarted. S156. Read the new configuration in the configuration system through the restarted OTG management service, and synchronously write the corresponding role value into the driver interface node of the Type-C controller.

[0056] Once the OTG event management process completes the verification of the target data role and target power role switch, it immediately performs a configuration status synchronization operation. The OTG event management process persists the currently effective data role, power role, and USB Type-C interface connection status to the corresponding configuration section of the configuration system via the configuration system write interface. The configuration system, acting as a centralized database for managing operational status and user preferences within the embedded device, updates its local configuration file upon receiving the write command. This synchronization operation ensures strict consistency between the management interface display status, the configuration file status, and the hardware role status of the Type-C controller. By eliminating the disconnect between the interface display, software records, and the actual operating status of the underlying hardware found in traditional architectures, the system provides an accurate data benchmark for subsequent status queries, policy reuse, and anomaly troubleshooting.

[0057] During system operation, when a role configuration modification request is received through the user interface, the system executes a dynamic configuration update process. After receiving modification instructions from the web management interface, device screen pop-ups, or command-line tools, the user interface submits configuration parameters, including new data roles, new power roles, or policy change notifications, to the configuration system. Upon receiving the modified configuration parameters, the configuration system performs configuration commit and persistent storage operations, generating a configuration change event. This configuration change event directly triggers an OTG management service restart via system signals or inter-process communication mechanisms. The restart mechanism is designed to ensure that the OTG event management process thoroughly clears the old state cache and pending event queue in memory, reloads the latest configuration parameters, and avoids role conflicts, state remnants, or business logic errors caused by incomplete hot configuration updates.

[0058] After responding to the restart command, the OTG management service enters the initialization loading phase. Upon restart, the OTG event management process first reads the new configuration from the configuration system, parsing out the target data role and target power role settings. Subsequently, the OTG event management process synchronously writes the parsed role values ​​to the Type-C controller's driver interface node via the operating system driver interface. The writing process follows a controlled negotiation mechanism; before writing, the OTG event management process verifies the Type-C controller's current negotiation state and physical connection stability, and issues a role switching request after the safe switching conditions are met. After receiving the new role values ​​from the driver interface node, the Type-C controller performs a low-level protocol handshake and hardware path switching, completing the final implementation from software configuration to hardware execution.

[0059] In one embodiment, when the status monitoring process captures a device removal event or unbinding event through a connection pin node level transition or kernel device event mechanism, the OTG event management process immediately determines that the USB Type-C interface has been disconnected. The OTG event management process then accesses the configuration system to locate and clean up the device list and status entries for the corresponding USB Type-C interface. Specifically, the connected peripheral identifiers, temporary session parameters, service association identifiers, and dynamically generated network configurations stored in the configuration system are removed or reset to their initial values ​​one by one. The configuration cleanup operation ensures that the configuration system no longer retains expired device contexts, preventing the reference of expired data during subsequent status queries or policy matching, and providing a clean configuration environment for the next device access.

[0060] While cleaning up configuration information, the OTG event management process executes stop or refresh operations on the service associated with the disconnected peripheral. The OTG event management process sends termination or reload commands to currently running service modules via inter-process communication interfaces. If the disconnected peripheral corresponds to a network sharing service, the system automatically removes network address translation rules, releases dynamically allocated IP addresses, and closes relevant firewall ports; if it corresponds to a network attached storage service, the system performs a file system security unmount operation, synchronizes cached data, and unpublishes the shared directory; if it corresponds to a wired network extension service, the system removes the virtual network card from the LAN bridging group and resets the network interface configuration. For service modules that support hot-swapping or need to run in the background, the system executes a service refresh process, reloading the default network topology and routing policies to ensure that service can smoothly degrade or recover to standby mode after losing underlying hardware support, avoiding the generation of zombie processes or resource leaks.

[0061] After the service processing is completed, the OTG event management process updates the connection status of the corresponding USB Type-C interface in the configuration system to a disconnected state and fully releases the allocated role resources. Role resource release includes resetting the status of the data role and power role, clearing the cache of the system file interface node, and destroying the device session context maintained in memory. The OTG event management process restores the data role node and power role node of the Type-C controller to their default safe values ​​or high-impedance state through the driver interface, cutting off external power supply paths or data enumeration requests, thus returning the hardware to a low-power standby mode. Simultaneously, the system releases the bus bandwidth, interrupt numbers, and memory mapping areas reserved for peripherals, ensuring that the embedded device's system resource pool is restored to its initial available state. The entire disconnection process strictly follows the sequence of configuration cleanup, service degradation, status update, and resource release, ensuring the closed-loop integrity of the system state machine.

[0062] In one embodiment, the OTG dual-role collaborative linkage method of the present invention further includes a dual-port independent management and collaborative arbitration mechanism. When the embedded device includes two USB Type-C interfaces, the embedded device executes the above-mentioned dual-port independent management and collaborative arbitration steps. First, the embedded device independently executes steps S110 to S160 for the first Type-C interface and the second Type-C interface respectively, wherein the first Type-C interface is a combined data and power port, and the second Type-C interface is an independent power port.

[0063] In terms of hardware topology, the first Type-C interface is managed by the first Type-C controller, which is responsible for the combined control of the data channel and the power channel; the second Type-C interface is managed by the second Type-C controller, which is mainly responsible for the independent control of the power channel.

[0064] In terms of software configuration, the configuration system sets up independent configuration sections for the first Type-C interface and the second Type-C interface, so that the first Type-C interface and the second Type-C interface can have their own independent data role configuration, power role configuration and connection status record, thereby realizing independent management of the dual ports.

[0065] The embedded device monitors the connection pin status of the first and second Type-C interfaces respectively, and independently updates the connection status of each interface in the configuration system. Specifically, the status monitoring module in the embedded device reads the connection pin nodes of the first and second Type-C controllers at preset intervals to obtain the physical connection status of the first and second Type-C interfaces. When a change in the connection pin status of the first or second Type-C interface is detected, the status monitoring module independently updates the connection status flag bit of the corresponding interface in the configuration system. For example, when the second Type-C interface is connected to an external power supply, the status monitoring module updates the connection status of the second Type-C interface in the configuration system and triggers a synchronization function to synchronize the power role configuration of the second Type-C interface, ensuring that the status of the independent power port is perceived by the system in real time.

[0066] When both the first and second Type-C interfaces are connected simultaneously, the embedded device generates a target role combination for the first and second Type-C interfaces based on a preset arbitration decision tree. The arbitration decision tree restricts only one controlled external power supply path to be active at any given time. In complex scenarios where both ports are plugged in simultaneously, the first and second Type-C interfaces may simultaneously request external power supply or compete for charging paths. Without restrictions, this could lead to power path conflicts, charging strategy preemption, or even triggering hardware overcurrent protection.

[0067] Therefore, embedded devices use an arbitration decision tree to coordinate the role requests of the first and second Type-C interfaces. When generating target role combinations, the arbitration decision tree strictly checks hardware mutual exclusion relationships to ensure that only one of the power supply paths of the first and second Type-C interfaces can be enabled at any given time. For example, if the arbitration decision tree determines that the second Type-C interface is used as a charging input, while the first Type-C interface needs to supply power to peripherals as a host, the arbitration decision tree allows the controlled power supply path of the first Type-C interface to take effect, while forcing the second Type-C interface to remain in charging receiving mode. If both the first and second Type-C interfaces request power supply, the arbitration decision tree selects a unique power supply path based on hardware priority, configuring the other interface to a waiting state or data-only mode. This achieves coordination at the software level with the underlying boost circuitry and path switches, completely preventing power path conflicts.

[0068] Furthermore, when the first Type-C interface and the second Type-C interface are simultaneously connected and generate role or power requests, the embedded device strictly executes the arbitration decision tree in descending order of priority to generate the target role combination of the first Type-C interface and the second Type-C interface.

[0069] The first priority of the arbitration decision tree is hardware safety status. The embedded device monitors the protection flags of the underlying hardware in real time. When any port of the first or second Type-C interface triggers overvoltage, overcurrent, temperature abnormality, or power path conflict, the arbitration decision tree immediately prohibits the external power supply requests of the first and second Type-C interfaces and forces the port with the abnormality to remain in or switch to a safe state. Specifically, the embedded device will revoke the Source role request to the Type-C controller at the software level and shut down the corresponding BOOST boost circuit and MOSFET path switch at the hardware level, causing the abnormal port to enter a high-impedance state or a Sink safe state, thereby preventing hardware damage or safety accidents at the highest priority.

[0070] Provided that a hardware safety condition is not triggered, the arbitration decision tree executes the second priority, namely the external charging input priority. When the embedded device detects a stable external adapter input at either the first or second Type-C interface via the Type-C controller, the arbitration decision tree prioritizes the corresponding port with the detected external adapter input as the charging receiver (Sink) and delegates the power path of that port to the charging management module within the embedded device. The charging management module specifically includes a main charging chip and a charge pump auxiliary charging chip, used to execute specific battery charging strategies to ensure that the embedded device's system power supply and battery charging are given priority.

[0071] Assuming the external charging input has been properly handled, the arbitration decision tree executes the third priority: data service priority. When the first Type-C interface needs to carry network sharing, network port expansion, storage, or device mode services, the arbitration decision tree prioritizes ensuring the stability of the first Type-C interface's data role. For example, when a USB flash drive or USB network card is connected to the first Type-C interface, the arbitration decision tree forcibly locks the target data role of the first Type-C interface as Host to prevent the data channel from being unexpectedly disconnected due to power negotiation. Simultaneously, the arbitration decision tree decides whether to allow the first Type-C interface to enable external power supply (Source) based on the peripheral's power requirements and the current system power status. If the second Type-C interface is already powering the system as a charging input, and hardware mutual exclusion allows, the arbitration decision tree allows the controlled external power supply path of the first Type-C interface to take effect.

[0072] Provided that data service constraints are met, the arbitration decision tree executes the fourth priority, namely the user's saved role configuration and the current user's selected priority. The embedded device reads the user role preferences saved in the configuration system for the first and second Type-C interfaces, or obtains the real-time role selection made by the current user through the user interaction interface. Without violating the aforementioned hardware security, external charging input, and data service constraints, the arbitration decision tree applies the user's configuration and selection as the target data role and target power role for the corresponding port, thereby respecting the user's intentions to the greatest extent possible within the scope of security and business requirements.

[0073] If, after the aforementioned four priority determinations, there are still unidentified conflict scenarios in the role requests of the first and second Type-C interfaces, or the capabilities of the peer device cannot be clearly matched, the arbitration decision tree will execute the fifth priority, namely the default security policy. Under the default security policy, the arbitration decision tree prioritizes maintaining the current charging input and system power supply stability, actively delaying the external power supply requests or role-flipping operations of the first or second Type-C interface, causing the conflicting port to enter a waiting state or data-only mode until the conflict condition is resolved or the user re-plugs or unplugs the device, triggering a new round of arbitration.

[0074] Under the five-level priority framework of the arbitration decision tree, the embedded device executes the corresponding specific execution branch according to the actual physical access scenario and role request of the first Type-C interface and the second Type-C interface.

[0075] If the second Type-C interface is used as a charging input and the first Type-C interface is connected to a peripheral device, the arbitration decision tree executes the first specific execution branch. In this scenario, the second Type-C interface is connected to an external power adapter. The arbitration decision tree locks the second Type-C interface as a charging receiver and hands it over to the charging management module inside the embedded device to ensure system power supply and battery charging. Simultaneously, if the first Type-C interface is connected to an external device, the arbitration decision tree selects the corresponding data and power role combination for the first Type-C interface based on the type of peripheral device connected. For example, if the first Type-C interface is connected to a USB flash drive or USB network adapter, the arbitration decision tree configures the first Type-C interface as both a Host (data) and Source (power) role, enabling the corresponding BOOST boost circuit and MOSFET path switch to supply power to the peripheral device. If the first Type-C interface is connected to a mobile phone for network sharing, the arbitration decision tree configures the first Type-C interface as a Host (data) role and, based on user role preferences or the phone's battery status in the configuration system, flexibly selects either a Source (power) role to reverse charge the phone or a Sink (power) role to receive power from the phone.

[0076] If the first Type-C interface is used as a charging input and the second Type-C interface requests external power, the arbitration decision tree executes the second specific execution branch. In this scenario, the first Type-C interface is connected to an external power source, while the second Type-C interface is connected to a peripheral device that requires power and requests external power. The arbitration decision tree first reads the embedded device's battery level, the boost capability of the BOOST boost circuit, and the protection status of the OVP overvoltage protection circuit. If it determines that the battery level is sufficient, the boost capability of the BOOST boost circuit meets the peripheral device's requirements, and no hardware protection status is triggered, the arbitration decision tree allows the second Type-C interface to enable external power supply, configures the target power source role of the second Type-C interface as Source, and enables the corresponding BOOST boost circuit and MOSFET path switch of the second Type-C interface; if it determines that the battery level is too low, the boost capability is insufficient, or there is a protection anomaly, the arbitration decision tree rejects the external power supply request of the second Type-C interface, keeps the second Type-C interface in a safe state, and prompts the user through the user interaction interface that the current battery level or hardware status does not support external power supply.

[0077] If the first Type-C interface and the second Type-C interface simultaneously request external power supply, or simultaneously compete for the charging path, the arbitration decision tree executes the third specific execution branch. Since hardware circuitry typically only allows one primary external power supply path or charging input path to be active, the arbitration decision tree selects the unique power supply or charging path based on a preset hardware mutual exclusion relationship. For example, if the first Type-C interface and the second Type-C interface simultaneously request external power supply, the arbitration decision tree prioritizes the external power supply request of the first Type-C interface, configuring the second Type-C interface to a waiting state or data-only mode. If the first Type-C interface and the second Type-C interface are simultaneously connected to an external power source and compete for the charging path, the arbitration decision tree negotiates the power output according to the external power adapter's PD protocol or a preset port charging priority, selecting the port with higher power or priority as the unique charging input path, configuring the other port to a waiting state or switching it to a high-impedance non-charging state, thereby completely preventing power path conflicts and charging strategy preemption.

[0078] The OTG dual-role collaborative linkage method of the present invention can be widely applied in the professional field of computer interface management and control with complex interface topology and high requirements for multi-role collaborative control and plug-and-play experience. The following uses two typical scenarios, industrial edge computing gateway and smart cockpit expansion dock, as examples for illustration.

[0079] In industrial edge computing gateway scenarios, this method can be used for dynamic access and automated management of interface roles for multi-source heterogeneous peripherals. Without manual intervention or device restarts for reconfiguration, the system automatically parses and re-determines interface roles layer by layer from underlying hardware interrupts and kernel events, generating the following end-to-end closed-loop control mapping: First, a dual-channel mechanism combining event-driven and low-frequency state verification accurately captures the physical connection and enumeration status of the Type-C interface. Then, based on driver features and a service mapping engine, the "5G communication module" is automatically linked as a network sharing service, and the "industrial sensor" is linked as a data acquisition service, ensuring that the interface data role and power role are not blindly defaulted to fixed combinations. Finally, a controlled write and secondary confirmation mechanism is used to output stable and coordinated interface role configuration data. This process not only significantly reduces the debugging and maintenance costs of complex peripheral access in industrial settings but also provides a basis for the data acquisition and network forwarding strategies of edge computing nodes, contributing to the automated management and stable operation of the Industrial Internet of Things (IIoT).

[0080] In smart cockpit docking applications, this method can be used for power path arbitration and data service collaborative management in scenarios with multiple Type-C interfaces concurrently. For example, in the recursive unfolding of complex operating conditions where devices with dual Type-C interfaces are simultaneously connected, the system automatically drills down from the arbitration node marked as "dual-port connection state," capturing the actual load attributes and power supply requests of the main data composite port and the independent power port, comparing the constraints of hardware safety status, external charging input, and data service priority, and thus generating a structured combination of independent dual-port roles. Passengers can not only experience seamless automatic triggering of services such as mobile network sharing, external storage mounting, or reverse charging, but also perceive the system's safety fallback and intelligent prompt logic based on the arbitration decision tree when dual-port power supply competes, enhancing safety and interactive experience in complex in-vehicle power and data interaction environments.

[0081] As can be seen from the above applications, the method of the present invention supports the collaborative linkage of interface roles with event-driven, hardware and software state synchronization and multi-port intelligent arbitration in fields with high reliability requirements and complex interface concurrency scenarios, such as industrial edge gateways and smart cockpit expansion docks. It has good practical value and development prospects.

[0082] Figure 8 This is a schematic block diagram of an OTG dual-role collaborative linkage device 600 provided in an embodiment of the present invention. Figure 8 As shown, corresponding to the above-described OTG dual-role collaborative linkage method, the present invention also provides an OTG dual-role collaborative linkage device 600. This OTG dual-role collaborative linkage device 600 includes a unit for executing the above-described OTG dual-role collaborative linkage method, and the device can be configured in a desktop computer, tablet computer, smartphone, or other terminal.

[0083] Specifically, please refer to Figure 8 The OTG dual-role collaborative linkage device 600 includes: The status monitoring unit 610 is used to monitor the connection status events of the USB Type-C interface, including kernel device events and status events generated based on the status changes of the connection pins of the Type-C controller. The information reading and status update unit 620 is used to read the initial connection information reported by the Type-C controller and update the connection status of the corresponding interface in the configuration system when the USB Type-C interface changes from an unconnected state to a connected state according to the connection status event. The initial connection information includes the connection pin status, dual-role capability identifier, and the current data role and current power role. The role determination unit 630 is used to determine the role capability type of the peer device based on the dual role capability identifier, and to determine the target data role and the target power role based on the role capability type and the user role preference in the configuration system. The role switching and verification unit 640 is used to write the target data role and the target power role as a role switching request into the driver interface of the Type-C controller when the preset switching conditions are met, and to perform switching verification through readback and event confirmation after writing. The peripheral device identification and service triggering unit 650 is used to identify the peripheral device type according to the driver information in the kernel device event after the switching verification is passed and the kernel device event is triggered, trigger the corresponding service based on the preset driver and service mapping relationship, and synchronously update the role status in the configuration system. The disconnection and cleanup unit 660 is used to clean up the device information and status items of the corresponding interface in the configuration system and stop or refresh the started service when the USB Type-C interface changes from a connected state to a disconnected state according to the connection status event.

[0084] In one embodiment, the status monitoring unit 610 includes: The kernel event registration unit is used to register and listen for device addition, binding, removal, unbinding, and restart events corresponding to the USB Type-C interface through the kernel device event mechanism. A pin status polling unit is used to read the connection pin nodes of the Type-C controller at a preset period to obtain the connection pin status. The state change triggering unit is used to trigger the state update of the configuration system and the subsequent role determination and switching process when a change in the state of the connection pin is detected.

[0085] In one embodiment, the information reading and status update unit 620 includes: The physical connection reading unit is used to read the connection pin nodes of the Type-C controller and obtain the physical connection status of the USB Type-C interface; The dual-role capability reading unit is used to read the dual-role capability node of the Type-C controller and obtain the dual-role capability identifier of the peer device; The current role reading unit is used to read the data role and power role currently reported by the Type-C controller, and use them as the current data role and the current power role; The pending negotiation state management unit is used to enter the pending negotiation state for dual-role devices that have not yet completed USB enumeration, based on the connection pin status and the dual-role capability identifier. The enumeration completion identification unit is used to perform subsequent peripheral type identification after the device role in the pending negotiation state has stabilized and the kernel device event has been generated.

[0086] In one embodiment, the role determination unit 630 includes: The configuration information reading unit is used to read the data role configuration, power role configuration and prompt flag of the corresponding interface in the configuration system when the dual-role capability identifier indicates that the peer device is a dual-role device. An interactive prompting and saving unit is used to prompt the user to select a combination of target data role and target power role through a user interaction interface if the prompting flag is enabled and there is no saved user role selection in the configuration system, and to save the selected role combination to the configuration system according to the user's wishes after the user makes the selection. The historical configuration application unit is used to directly apply the saved data role and power role as the target data role and the target power role if there is a saved user role selection in the configuration system. The single-role automatic determination unit is used to automatically determine the target data role and the target power role based on the capabilities of the single-role device when the dual-role capability identifier indicates that the peer device is a single-role device.

[0087] In one embodiment, the role switching and verification unit 640 includes: A pre-verification unit is used to read the current role, connection status, and negotiation status of the Type-C controller before writing the role switching request; The delay waiting unit is used to delay writing and wait for the state to stabilize if the Type-C controller is in the process of protocol negotiation or the connection pin state is unstable; The role request writing unit is used to write the target data role to the data role node of the Type-C controller and the target power role to the power role node of the Type-C controller when the switching conditions are met. The secondary verification unit is used to perform secondary verification after the write operation by using the node readback of the driver interface, the kernel device event, and the peripheral enumeration result. If the verification is successful, the switch verification is determined to be passed.

[0088] In one embodiment, the peripheral device identification and service triggering unit 650 includes: The driver information extraction unit is used to extract driver name, subsystem identifier, interface information, device name or supplier identifier and product identifier from the kernel device events; A mapping relationship matching unit is used to perform matching in the driver-business mapping relationship based on the extracted information; The business service invocation unit is used to invoke the matched business service through the inter-process call interface and trigger the corresponding business event.

[0089] Furthermore, the peripheral identification and service triggering unit 650 also includes: The status synchronization writing unit is used to write the current data role, power role and connection status into the configuration system after the role switch is completed, so that the status displayed on the management interface and the configuration file status are consistent with the hardware role status of the Type-C controller. The configuration modification triggering unit is used to write the modified configuration into the configuration system and trigger the OTG management service to restart when a role configuration modification request is received through the user interaction interface. The restart synchronous write unit is used to read the new configuration in the configuration system through the restarted OTG management service and synchronously write the corresponding role value to the driver interface node of the Type-C controller.

[0090] Please see Figure 9 , Figure 9 This is a schematic block diagram of a computer device 500 provided in an embodiment of this application. The computer device 500 can be a terminal or a server. The terminal can be an electronic device with communication functions, such as a desktop computer, tablet computer, or smartphone. The server can be a standalone server or a server cluster composed of multiple servers.

[0091] See Figure 9 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0092] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform an OTG dual-role cooperative linkage method.

[0093] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0094] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an OTG dual-role collaborative linkage method.

[0095] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0096] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of the above method.

[0097] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0098] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0099] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the steps of the above-described method.

[0100] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0101] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0102] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0103] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0104] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0105] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0106] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An OTG dual-role collaborative linkage method, applied to an embedded device, the embedded device including at least one USB Type-C interface supporting OTG function and a Type-C controller managing the USB Type-C interface, characterized in that, The method includes: Listen for connection status events of the USB Type-C interface, including kernel device events and status events generated based on changes in the connection pin status of the Type-C controller; When the USB Type-C interface changes from an unconnected state to a connected state based on the connection state event, the initial connection information reported by the Type-C controller is read and the connection state of the corresponding interface in the configuration system is updated. The initial connection information includes the connection pin status, dual-role capability identifier, and the current data role and current power role. The role capability type of the peer device is determined based on the dual-role capability identifier, and the target data role and target power role are determined based on the role capability type and the user role preference in the configuration system. When the preset switching conditions are met, the target data role and the target power role are written as a role switching request to the driver interface of the Type-C controller, and the switching is verified by readback and event confirmation after writing. Once the switchover verification is successful and the kernel device event is triggered, the peripheral type is identified based on the driver information in the kernel device event, the corresponding business service is triggered based on the preset driver-business mapping relationship, and the role status in the configuration system is updated synchronously. When the USB Type-C interface changes from a connected state to a disconnected state based on the connection status event, the device information and status items of the corresponding interface in the configuration system are cleared, and the started service is stopped or refreshed.

2. The OTG dual-role collaborative linkage method according to claim 1, characterized in that, The step of listening to the connection status events of the USB Type-C interface, wherein the connection status events include kernel device events and status events generated based on changes in the connection pin status of the Type-C controller, includes: Register and listen for device addition, binding, removal, unbinding, and restart events corresponding to the USB Type-C interface through the kernel device event mechanism; The connection pin nodes of the Type-C controller are read at a preset period to obtain the status of the connection pins; When a change in the state of the connection pin is detected, the state update of the configuration system and the subsequent role determination and switching process are triggered.

3. The OTG dual-role collaborative linkage method according to claim 1, characterized in that, The step of reading the initial connection information reported by the Type-C controller and updating the connection status of the corresponding interface in the configuration system when the USB Type-C interface changes from an unconnected state to a connected state based on the connection status event includes: Read the connection pin nodes of the Type-C controller to obtain the physical connection status of the USB Type-C interface; Read the dual-role capability node of the Type-C controller to obtain the dual-role capability identifier of the peer device; Read the data role and power role currently reported by the Type-C controller, and use them as the current data role and the current power role; For dual-role devices that have not yet completed USB enumeration, they enter a pending negotiation state based on the connection pin status and the dual-role capability identifier. Once the device role in the pending negotiation state is stable and the kernel device event is generated, the subsequent peripheral type identification will be performed.

4. The OTG dual-role collaborative linkage method according to claim 1, characterized in that, The steps of determining the role capability type of the peer device based on the dual-role capability identifier, and determining the target data role and target power role based on the role capability type and the user role preferences in the configuration system include: When the dual-role capability identifier indicates that the peer device is a dual-role device, read the data role configuration, power role configuration and prompt flag of the corresponding interface in the configuration system; If the prompt flag is enabled and there is no saved user role selection in the configuration system, the user is prompted to select a combination of target data role and target power role through the user interaction interface, and the selected role combination is saved to the configuration system according to the user's wishes after the user makes the selection. If there are already saved user role selections in the configuration system, the saved data role and power role are directly applied as the target data role and the target power role. When the dual-role capability identifier indicates that the peer device is a single-role device, the target data role and the target power role are automatically determined based on the capabilities of the single-role device.

5. The OTG dual-role collaborative linkage method according to claim 1, characterized in that, The step of writing the target data role and the target power role as a role switching request to the driver interface of the Type-C controller when the preset switching conditions are met, and verifying the switching through readback and event confirmation after writing, includes: Before writing the role switching request, read the current role, connection status, and negotiation status of the Type-C controller; If the Type-C controller is in the process of protocol negotiation or the connection pin state is unstable, the write operation is delayed and the process waits for the state to stabilize. Once the switching conditions are met, the target data role is written to the data role node of the Type-C controller, and the target power role is written to the power role node of the Type-C controller. After the write operation, a second confirmation is performed through node readback of the driver interface, kernel device events, and peripheral enumeration results. Once the confirmation is successful, the switchover verification is deemed to have passed.

6. The OTG dual-role collaborative linkage method according to claim 1, characterized in that, The step of identifying the peripheral type based on the driver information in the kernel device event and triggering the corresponding service based on the preset driver-service mapping relationship includes: Extract the driver name, subsystem identifier, interface information, device name or vendor identifier and product identifier from the kernel device events; The extracted information is used to perform matching in the driver-business mapping relationship; By calling the matched business service through the inter-process call interface, the corresponding business event is triggered.

7. The OTG dual-role collaborative linkage method according to claim 6, characterized in that, The steps for synchronously updating the role status in the configuration system include: After the role switch is completed, the current data role, power role and connection status are written into the configuration system to ensure that the management interface display status, configuration file status and the hardware role status of the Type-C controller are consistent. When a role configuration modification request is received through the user interaction interface, the modified configuration is written to the configuration system and the OTG management service is restarted. The restarted OTG management service reads the new configuration from the configuration system and synchronously writes the corresponding role values ​​into the driver interface node of the Type-C controller.

8. An OTG dual-role collaborative linkage device, characterized in that, Used to perform the OTG dual-role collaborative linkage method as described in any one of claims 1 to 7.

9. A computer device, characterized in that, The computer device includes a memory and a processor connected to the memory; the memory is used to store a computer program; the processor is used to run the computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which includes program instructions that, when executed by a processor, can implement the steps of the method as described in any one of claims 1 to 7.

Images