Charging control method and system based on linux system kernel module

Abstract

The present disclosure provides a charging control method and system based on a Linux system kernel module, the method comprising: traversing a device registration list of an electronic system by a kernel module preset in a Linux system, identifying a charging device and a battery device, and associating the charging device and the battery device; generating a cooling device operation interface corresponding to the charging device, calling the cooling device operation interface by a cooling module in the Linux system, and forming a heat dissipation instruction based on a real-time temperature of the battery device; converting the heat dissipation instruction into a charging control instruction and sending the charging control instruction to a driving chip of the charging device to enable the driving chip to adjust a running parameter of the charging device based on the charging control instruction. The present application can control the charging of the charging device through the Linux system kernel module without modifying the kernel architecture of the Linux system, thereby reducing the development cost and improving the charging control efficiency and accuracy.

Description

Technical Field

[0001] This disclosure relates to the field of computers. More specifically, it relates to a charging control method and system based on a Linux system kernel module. Background Technology

[0002] Currently, within the Linux operating system ecosystem, while charging device integrated circuit (IC) drivers for different hardware platforms adhere to basic power supply system specifications, they exhibit significant fragmentation in terms of control interfaces, attribute definitions, and capability set implementations. Drivers from different manufacturers differ in system file node names, numerical formats, and operational logic for functions such as charging current regulation, charge / discharge enable, and fast charging protocol control. Furthermore, the charging hardware capabilities of embedded devices, desktop devices, and industrial equipment vary greatly, ranging from low-end ICs that only support charge / discharge start / stop to high-end chips that support multi-level current regulation and fast charging protocols. Existing operating systems typically require user-space configuration of specially customized drivers for charging devices to achieve charging control. These drivers require individual configuration for each charging device, increasing labor costs and leading to low charging control efficiency due to untimely environmental information perception. Moreover, the drivers lack universality and cannot achieve adaptable, universal control for various charging devices. Summary of the Invention

[0003] To address at least one of the above problems, one objective of this application is to provide a charging control method based on a Linux system kernel module. Another objective of this application is to provide a Linux system.

[0004] This application discloses a charging control method based on a Linux system kernel module, including: The system uses a pre-installed kernel module in Linux to traverse the device registration list of the power supply system, identify charging devices and battery devices, and associate charging devices and battery devices. A cooling device operation interface corresponding to the charging device is generated, and the cooling module in the Linux system calls the cooling device operation interface to generate a heat dissipation command based on the real-time temperature of the battery device. The heat dissipation command is converted into a charging control command and sent to the driver chip of the charging device so that the driver chip adjusts the operating parameters of the charging device based on the charging control command.

[0005] Optionally, this further includes traversing the device registry list of the power supply system via a kernel module pre-installed in the Linux system: The generic_charging_cooling.ko kernel module for charging control is compiled, and the generic_charging_cooling.ko kernel module is a loadable kernel module supported by the Linux system; The generic_charging_cooling.ko kernel module is pre-installed on the Linux system using the insmod command.

[0006] Optionally, the step of generating the cooling device operation interface corresponding to the charging device includes: Obtain the preset attribute file of the charging device; The hardware capability set of the charging device is determined based on the preset attribute file. The hardware capability set includes the power supply controllability parameters of the charging device and their parameter ranges. The cooling device operation interface corresponding to the charging device is generated based on the hardware capability set.

[0007] Optionally, the process of obtaining the preset attribute file of the charging device includes: The sysfs file of the charging device is obtained through the standardized kernel exposure interface of the power supply system, and the preset attribute file is obtained.

[0008] Optionally, generating the cooling device operation interface corresponding to the charging device based on the hardware capability set includes: Based on the power supply controllability parameters and parameter range of the charging device, a corresponding control level and parameter values ​​corresponding to the control level are generated, wherein the range of parameter values ​​of the control level is within the parameter range; The current real-time control level of the charging device is determined based on the current charging current of the charging device, and the standardized attributes corresponding to the real-time control level are determined based on the power supply controllability parameters. The control level, the parameter values ​​corresponding to each control level, the real-time control level, and the standardized attributes are encapsulated into a cooling equipment operation interface that can be called by the cooling module.

[0009] Optionally, the step of generating a corresponding control level and parameter values ​​corresponding to the control level based on the power supply controllability parameters and parameter ranges of the charging device includes: When the power supply controllability parameter supports continuous adjustment within the parameter range, a linear mapping relationship between the control level and the charging current is established. When the power supply controllability parameter supports discrete level adjustment within the parameter range, a discrete mapping relationship between the control level and the charging level is established. When the power supply controllability parameter is set to only support charge and discharge enable control within the parameter range, a binary mapping relationship between the control level and the charge and discharge enable state is established.

[0010] Optional, further including: The control levels, parameter values ​​corresponding to each control level, and standardized attributes in the operation interface of the cooling equipment are respectively associated with multiple preset temperature threshold ranges of the corresponding battery equipment to form a preset association relationship.

[0011] Optionally, the heat dissipation command based on the real-time temperature of the battery device includes: The target preset temperature threshold range of the battery device is determined based on the real-time temperature of the battery device. The target control level corresponding to the target preset temperature threshold range is determined based on the preset correlation relationship; Based on the real-time control level of the charging device, the target control level, the parameter values ​​corresponding to the target control level, and standardized attributes, a heat dissipation command is generated from the cooling module to control the cooling device.

[0012] Optional, further including: In response to the device deregistration request from the charging device driver chip, the cooling device operation interface is deleted, related data within the Linux kernel is deleted, and the occupied Linux kernel memory is released.

[0013] This application also discloses a Linux system, including a kernel module configured to traverse the device registration list of the power supply system, identify charging devices and battery devices, and associate charging devices and battery devices; generate a cooling device operation interface corresponding to the charging device; call the cooling device operation interface through the cooling module in the Linux system; generate a heat dissipation command based on the real-time temperature of the battery device; convert the heat dissipation command into a charging control command and send it to the driver chip of the charging device so that the driver chip adjusts the operating parameters of the charging device based on the charging control command.

[0014] The beneficial effects of this disclosure are as follows: This application identifies charging devices within the Linux kernel environment through kernel modules and generates a cooling device operation interface for the charging devices. The cooling module can obtain relevant parameters of the charging devices through this interface by controlling the cooling device. Based on the real-time temperature of the associated battery device and the relevant parameters obtained through the cooling device operation interface, a heat dissipation command is generated in real time. This heat dissipation command is converted into a charging control command and sent to the driver chip for execution, thus achieving kernel-level charging control of the charging devices. The charging device control in this application is based on the real-time temperature of the battery device, allowing direct sensing of the battery device's temperature information for charging regulation, improving charging control efficiency and accuracy. This application eliminates the need for separate development and customization of charging device drivers in user space, reducing development costs. Furthermore, this application does not require modification of the Linux kernel architecture to control charging devices through Linux kernel modules, demonstrating broad applicability. Attached Figure Description

[0015] The specific embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0016] Figure 1 This diagram illustrates the principle of a charging control method based on a Linux system kernel module according to an embodiment of the present disclosure. Figure 2 A flowchart illustrating a charging control method based on a Linux system kernel module according to an embodiment of this disclosure is shown. Figure 3 This diagram illustrates a flowchart of the kernel module configuration for a charging control method based on a Linux system kernel module according to an embodiment of the present disclosure; Figure 4 The flowchart illustrates a charging control method S200 based on a Linux system kernel module according to an embodiment of the present disclosure; Figure 5 The flowchart illustrates a charging control method S230 based on a Linux system kernel module according to an embodiment of this disclosure; Figure 6 This diagram shows a flowchart of a charging control method S231 based on a Linux system kernel module according to an embodiment of the present disclosure; Figure 7 The flowchart illustrates a charging control method S200 based on a Linux system kernel module according to an embodiment of the present disclosure, which generates a heat dissipation command. Detailed Implementation

[0017] To more clearly illustrate this disclosure, the following description, in conjunction with embodiments and accompanying drawings, provides further insight. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of this disclosure.

[0018] Currently, within the Linux operating system ecosystem, while charging device integrated circuit (IC) drivers for different hardware platforms adhere to basic power supply system specifications, they exhibit significant fragmentation in terms of control interfaces, attribute definitions, and capability set implementations. Drivers from different manufacturers differ in system file node names, numerical formats, and operational logic for functions such as charging current adjustment, charge / discharge enable, and fast charging protocol control. Furthermore, the charging hardware capabilities of embedded devices, desktop devices, and industrial equipment vary greatly, ranging from low-end ICs that only support charge / discharge start / stop to high-end chips that support multi-level current adjustment and fast charging protocols. Existing operating systems typically require user-space configuration of specially customized drivers for charging devices to achieve charging control.

[0019] These drivers require separate configurations or modifications to the operating system framework for each charging device to achieve charging control. This not only increases labor costs but also leads to low charging control efficiency due to untimely environmental information perception. Furthermore, the drivers lack universality and cannot achieve adaptable and universal control for various charging devices. For example, existing charging control schemes based on ChromeOS embedded controllers modify the cros_usbpd_charger driver source code to implement the linkage between charging current limiting and thermal management within the driver. This scheme uses hard-coded fixed cooling levels and current mapping relationships within the driver, which can only adapt to ChromeOS-specific charging hardware and drivers and cannot run on Linux devices.

[0020] In order to solve at least one of the problems existing in the prior art, according to one aspect of this application, such as Figure 1 and Figure 2 As shown in the figure, this embodiment discloses a charging control method based on a Linux system kernel module, the method comprising: S100: It uses the kernel modules pre-installed in the Linux system to traverse the device registration list of the power supply system, identify charging devices and battery devices, and associate charging devices and battery devices.

[0021] S200: Generate the cooling device operation interface corresponding to the charging device, call the cooling device operation interface through the cooling module in the Linux system, and generate a heat dissipation command based on the real-time temperature of the battery device.

[0022] S300: The heat dissipation command is converted into a charging control command and sent to the driver chip of the charging device, so that the driver chip adjusts the operating parameters of the charging device based on the charging control command. It should be noted that these operating parameters include, but are not limited to, parameters such as the charging current and standardized attributes of the charging device, and this application does not limit them.

[0023] This application identifies charging devices within the Linux kernel environment through kernel modules and generates a cooling device operation interface for the charging devices. This allows the cooling module to obtain relevant parameters of the charging devices through the cooling device operation interface by controlling the cooling device. Based on the real-time temperature of the associated battery device and the relevant parameters obtained through the cooling device operation interface, a heat dissipation command is generated in real time. This heat dissipation command is then converted into a charging control command and sent to the driver chip, such as TI BQ series, Richtek RT series, embedded AXP series, or ChromeOS EC dedicated charging chips. The driver chip executes this command to achieve kernel-level charging control of the charging devices. The charging device control in this application is based on the real-time temperature of the battery device, allowing direct sensing of the battery device's temperature information for charging regulation, improving charging control efficiency and accuracy. This application eliminates the need for separate development and customization of charging device drivers in user space, reducing development costs. Furthermore, this application does not require modification of the Linux kernel architecture to control charging devices through Linux kernel modules, demonstrating broad applicability.

[0024] In alternative implementations, such as Figure 3 As shown, the method further includes the step of configuring the kernel module before traversing the device registry list of the power supply system via a pre-installed kernel module in the Linux system: S010: Compile to obtain the generic_charging_cooling.ko kernel module for charging control. The generic_charging_cooling.ko kernel module is a loadable kernel module supported by the Linux system.

[0025] S020: Pre-install the generic_charging_cooling.ko kernel module in the Linux system using the insmod command.

[0026] In the embodiments of this application, it is understood that the existing ChromeOS solution is implemented by modifying the driver source code, which must be integrated into a custom kernel and cannot be deployed on existing devices. This application compiles a kernel module using a loadable kernel module (LKM) supported by the Linux system. It can non-intrusively utilize the existing cooling module in the system kernel to control the cooling device's charging function. It can be directly loaded and run on any mainstream Linux system or embedded Linux system without modifying the system, making it highly practical for deployment.

[0027] In practical applications, the compilation and deployment of kernel modules must be completed before charging control can be implemented. The Linux system provides a loadable kernel module feature, allowing users to compile independent functional code into separate kernel module files, which are then dynamically loaded into the kernel space during system operation without modifying the kernel source code or recompiling the entire system kernel. During compilation, corresponding kernel module code can be written based on the kernel development environment provided by the Linux system. This kernel module code needs to be able to implement the charging control method of this application after being compiled and deployed into the Linux system kernel. Those skilled in the art can write the kernel module code required for this application according to the Linux system kernel development requirements in the prior art; this is a conventional technical method in the field and will not be elaborated further here.

[0028] It's important to note that the compilation process requires kernel header files that are completely compatible with the target Linux system's kernel version. This ensures that the compiled kernel modules can be loaded and run correctly on the target system. Kernel header files are typically provided by the Linux distribution's software repositories, and users can install them directly using the system's package manager, without needing to manually download and compile the kernel source code. The Makefile used for compilation is built based on the Linux kernel's native compilation framework, eliminating the need for custom compilation rules and ensuring the compatibility and stability of the compilation process.

[0029] After the kernel module code is generated, it can be compiled into the generic_charging_cooling.ko kernel module file using the compilation framework provided by the kernel. The compiled kernel module file can then be loaded into the running Linux system kernel space using the insmod command provided by the Linux system, completing the pre-installation of the kernel module. After the kernel module is loaded, initialization operations will be performed in the kernel space, providing the operational foundation for subsequent device identification and charging control.

[0030] In this embodiment, after the kernel module is pre-configured using the `insmod` command, the Linux system performs a validity check on the kernel module. This check includes verifying the module's kernel version compatibility, the validity of its digital signature, and the compliance of its code format. If the check passes, the system loads the kernel module's code into a dedicated memory area in the kernel space, executes the module's initialization function, and completes the setup of the module's runtime environment. The initialization function creates a dedicated data structure in the kernel space to store device information, capability sets, mapping relationships, and other data generated in subsequent processes. It also registers event listener callbacks with relevant kernel subsystems to monitor events such as device registration, deregistration, and status changes.

[0031] In this embodiment, after the kernel module initialization is complete, the pre-installed kernel module in the Linux system traverses the device registration list of the power supply system, identifies charging devices and battery devices, and associates them. The power supply system (power_supply) is a standardized subsystem in the Linux kernel used to manage various power-related devices. All charging devices and battery devices conforming to the Linux kernel specification will register with this subsystem during driver loading, forming a corresponding device registration list. The device registration list is updated in real time. When a new power device is connected to the system, the corresponding driver will register the device with the power supply system and add the device information to the device registration list; when a power device is removed from the system, the corresponding driver will send a deregistration request to the power supply system to remove the device information from the device registration list.

[0032] In this embodiment, the process of the kernel module traversing the device registration list is completed through the device traversal interface provided by the power supply system. This traversal interface allows the kernel module to traverse all registered devices under the power supply system, obtaining basic information, device type, attribute list, etc., for each device. During the traversal, the kernel module accesses each device node in the device registration list one by one, reading the device's basic information to provide a data foundation for subsequent device identification. The traversal process is completed in kernel space without user-space involvement, and the traversal latency is at the millisecond level, which will not affect the normal operation of the system. For example, all devices under the power_supply device class can be traversed through the kernel's native class_for_each_device function, i.e., the device registration list can be traversed.

[0033] In this embodiment, after traversing the device registration list, the kernel module identifies charging devices and battery devices based on the device information obtained during the traversal. During device identification, the kernel module reads the device type attribute of each registered device. This attribute, submitted by the device driver to the power supply system during registration, identifies the device's functional type and is a standardized device classification attribute of the Linux kernel. When the device type attribute is identified as a power input device, the kernel module identifies the device as a charging device; when the device type attribute is identified as a battery storage device, the kernel module identifies the device as a battery device. During identification, the kernel module simultaneously records the unique identification information of each device. This identification information is automatically generated by the power supply system during device registration and is used to uniquely identify a power device for subsequent device access and control. For example, by reading the device type attribute POWER_SUPPLY_PROP_TYPE, the kernel module can automatically distinguish between battery devices (device type attribute identifier: POWER_SUPPLY_TYPE_BATTERY) and charging devices (device type attribute identifier: POWER_SUPPLY_TYPE_MAINS / USB / ADP).

[0034] It should be noted that during device identification, the kernel module filters out power devices that are not related to charging and discharging, including peripheral power supplies, system standby power supplies, and backlight power supplies, retaining only charging devices and battery devices directly related to battery charging and discharging. This prevents irrelevant devices from interfering with subsequent control processes. The filtering process is based on device type attributes and device function descriptions, ensuring that only devices related to charging and discharging control are retained.

[0035] For example, in a Linux device, the device registry list for the power supply system contains three devices: device A, device B, and device C. During the kernel module's traversal, it reads that device A's device type attribute is power input and identifies it as a charging device; it reads that device B's device type attribute is battery storage and identifies it as a battery device; it reads that device C's device type attribute is peripheral power supply and filters it out, excluding it from the identification range of charging and battery devices.

[0036] In this embodiment, after identifying the charging device and the battery device, the kernel module associates the charging device and the battery device. The device association process establishes a mapping relationship between the charging device and the corresponding battery device, ensuring that subsequent charging control operations can be applied to the correct device combination and avoiding control errors due to mismatch between the charging device and the battery device. During the association process, the kernel module first reads the device's hardware topology information. This hardware topology information describes the device's mounting location on the system hardware bus, its associated link, and its upstream controller. Based on the device's mounting relationship on the hardware bus, an association can be established between the charging device and the battery device under the same power supply link. For devices that cannot be associated through hardware topology information, the kernel module completes the association based on the device's status linkage information. When the operating state of a charging device changes, the charging state of the corresponding battery device changes synchronously; based on this linkage, the device association is completed. After the association is completed, the kernel module stores the association relationship in a dedicated data structure in the kernel space for subsequent process calls.

[0037] It should be noted that for devices containing multiple groups of charging devices and battery devices, the kernel module will establish corresponding associations for each group of charging devices and battery devices based on hardware topology information and status linkage information. This ensures that each group of devices can independently complete charging and discharging control without interference between groups. After the associations are established, the kernel module will register status listening callbacks with the kernel's device management subsystem. When the device's hardware topology or operating status changes, the associations will be automatically updated to ensure their accuracy.

[0038] For example, a Linux device may contain two independent charging / discharging links. The first link includes charging device A and battery device B, while the second link includes charging device E and battery device D. The kernel module reads the hardware topology information and finds that charging device A and battery device B are connected to the same I2C bus's first channel, and charging device E and battery device D are connected to the same I2C bus's second channel. Therefore, it can establish the association between charging device A and battery device B, and the association between charging device E and battery device D, forming two independent charging / discharging device combinations.

[0039] In alternative implementations, such as Figure 4 As shown, the step S200 generates the cooling device operation interface corresponding to the charging device, including: S210: Obtain the preset attribute file of the charging device.

[0040] S220: Determine the hardware capability set of the charging device based on the preset attribute file. The hardware capability set includes the power supply controllability parameters of the charging device and their parameter ranges.

[0041] S230: Generate the cooling device operation interface corresponding to the charging device based on the hardware capability set.

[0042] In an optional implementation, S210 acquiring the preset attribute file of the charging device includes: S211: Obtain the sysfs file of the charging device through the standardized kernel exposure interface of the power supply system, and obtain the preset attribute file.

[0043] In this embodiment, after the identification and association between the charging device and the battery device are completed, a cooling device operation interface corresponding to the charging device is generated. During the generation of the cooling device operation interface, the preset attribute file of the charging device is first obtained. The preset attribute file is obtained through the standardized kernel exposure interface of the power supply system. Each device registered with the power supply system generates a dedicated set of sysfs file directories. Each file in the directory corresponds to an attribute of the device, used to read the device status or write control parameters. The kernel module reads all files in the sysfs file directory corresponding to the charging device through the standardized kernel exposure interface provided by the power supply system, thus obtaining the preset attribute file of the charging device.

[0044] It's important to note that the sysfs file is a standardized device access interface provided by the Linux kernel. All device drivers conforming to the kernel specification implement the corresponding sysfs file access logic, including read and write callback functions for the attribute file, eliminating the need to develop dedicated access interfaces for specific drivers. Kernel modules can obtain all accessible attributes of the charging device by reading the sysfs file, without relying on private interfaces provided by the driver, ensuring the solution's universality and compatibility. The sysfs file access process is entirely completed in kernel space, with access latency at the microsecond level, enabling fast reading and writing of device attributes.

[0045] For example, after the kernel module completes the identification of the charging device, it accesses the sysfs file directory corresponding to the charging device through the standardized kernel exposure interface of the power supply system. It reads all the sysfs files in the directory, including files for setting the charging current, files for controlling charge / discharge enable, files for reading the device's maximum supported current, and files for reading the device's operating status. These read files together constitute the preset attribute file of the charging device. Of course, in practical applications, preset attribute files can also be formed in other ways as needed, and this application does not limit this.

[0046] In this embodiment, after obtaining the preset attribute file of the charging device, the hardware capability set of the charging device is determined based on the attribute file. The hardware capability set includes the power supply controllability parameters of the charging device and their parameter ranges. The hardware capability set describes all control functions that the charging device can support, and the parameter ranges corresponding to each control function. Specifically, it includes the power supply controllability parameters of the charging device, and the adjustable range corresponding to each power supply controllability parameter. During the process of determining the hardware capability set, the kernel module verifies each attribute file in the preset attribute file one by one, determining whether the attribute file is readable, whether it is writable, and the writable parameter range. Based on the verification results, the hardware capability set of the charging device is obtained.

[0047] It should be noted that power supply controllable capability parameters include controllable parameters related to the power output of the charging device, such as charging current regulation capability, charge / discharge enable control capability, fast charging protocol control capability, and input voltage regulation capability. Each power supply controllable capability parameter corresponds to a parameter range, including the minimum and maximum settable values, as well as the step precision for parameter adjustment. The kernel module organizes all verified power supply controllable capability parameters and their ranges into a standardized hardware capability set, storing it in a dedicated data structure in the kernel space for subsequent process calls. During the verification process, for attribute files that are read-only and not write-only, only their device status reading capability range is included, not the power supply controllable capability parameter range, ensuring that only parameters that can be actively controlled are retained.

[0048] For example, after obtaining the preset attribute files of a charging device, the kernel module verifies each attribute file one by one. It finds that the device contains a writable charging current setting attribute file. Reading the parameter range of this attribute file, it obtains that the minimum settable charging current for the device is 0 mA, the maximum is 3000 mA, and the step precision is 100 mA. It also finds that the device contains a writable charge / discharge enable attribute file, with writable parameter values ​​of 0 or 1, corresponding to turning charging off and on, respectively. No writable fast charging protocol control attribute file is found. Based on the above verification results, the kernel module compiles the device's hardware capability set, which includes two controllable power supply capability parameters: charging current adjustment and charge / discharge enable, as well as the adjustable range of each parameter.

[0049] In alternative implementations, such as Figure 5 As shown, step S230, based on the hardware capability set, generates the cooling device operation interface corresponding to the charging device, including: S231: Based on the power supply controllability parameters and parameter range of the charging device, generate a corresponding control level and parameter values ​​corresponding to the control level, wherein the range of parameter values ​​for the control level is within the parameter range.

[0050] S232: Determine the current real-time control level of the charging device based on the current charging current of the charging device, and determine the standardized attributes corresponding to the real-time control level based on the power supply controllability parameters.

[0051] S233: The control level, the parameter values ​​corresponding to each control level, the real-time control level, and the standardized attributes are encapsulated into a cooling equipment operation interface that can be called by the cooling module.

[0052] In this embodiment, after determining the hardware capability set of the charging device, a cooling device operation interface corresponding to the charging device is generated based on the hardware capability set. During the generation of the cooling device operation interface, a corresponding control level and parameter value corresponding to the control level are first generated based on the power supply controllability parameters and their ranges of the charging device. The range of parameter values ​​for each control level is within the parameter range. The control level is used to convert the continuous or discrete controllable parameters of the charging device into a standardized level sequence recognizable by the cooling module. By outputting different control levels, the cooling module can achieve different degrees of control over the charging device. The number and range of control levels are dynamically determined based on the hardware capability set of the charging device, ensuring that the parameter value corresponding to each control level is within the range supported by the device, and preventing control operations that exceed the device's capabilities.

[0053] It should be noted that the control level value is positively correlated with the cooling control intensity. The higher the control level value, the stronger the corresponding cooling control, the lower the output current of the charging device, and the better the heat dissipation effect. The minimum control level value is 0, corresponding to the maximum output current of the charging device, with no cooling control. The maximum control level value is dynamically determined based on the hardware capability set, corresponding to the minimum output current of the charging device, or the charging off state, achieving the highest intensity of cooling control.

[0054] For example, a charging device has centralized hardware capabilities, with its controllable power supply parameter being charging current regulation, corresponding to a parameter range of 0 mA to 3000 mA and a step precision of 100 mA. Based on this parameter range, the kernel module generates 11 consecutive control levels, ranging from 0 to 10. Level 0 corresponds to a parameter value of 3000 mA, level 10 corresponds to a parameter value of 0 mA, the parameter value difference between each adjacent level is 300 mA, and the parameter values ​​corresponding to all levels are within the parameter range of 0 mA to 3000 mA.

[0055] In alternative implementations, such as Figure 6 As shown, step S231 generates a corresponding control level and parameter values ​​corresponding to the control level based on the power supply controllability parameters and parameter ranges of the charging device, including: S2311: When the power supply controllability parameter supports continuous adjustment within the parameter range, a linear mapping relationship between the control level and the charging current is established.

[0056] S2312: When the power supply controllability parameter supports discrete level adjustment within the parameter range, establish a discrete mapping relationship between the control level and the charging level.

[0057] S2313: When the power supply controllability parameter is only supported within the parameter range for charge and discharge enable control, a binary mapping relationship between the control level and the charge and discharge enable state is established.

[0058] In this embodiment, during the generation of control levels and corresponding parameter values, different mapping methods are used to establish the correspondence between control levels and parameter values ​​based on the type of power supply controllability parameter of the charging device. When the parameter range indicated by the power supply controllability parameter is continuous current adjustment, the kernel module establishes a linear mapping relationship between the control level and the charging current. In this linear mapping relationship, the value of the control level and the value of the charging current are negatively correlated; the higher the value of the control level, the lower the corresponding charging current value, ensuring that the control level output by the cooling module is higher and the cooling control intensity of the charging device is higher.

[0059] It should be noted that continuous current regulation refers to the charging device's ability to continuously adjust the charging current value between its minimum and maximum values ​​with fixed step precision, achieving smooth adjustment of the charging current. During the establishment of the linear mapping relationship, the adjustable range of the charging current is divided into intervals corresponding to the total number of control levels, with each interval corresponding to one control level. This ensures a stable linear correspondence between the control levels and the charging current. Establishing this linear mapping relationship ensures a stable correspondence between the control level output by the cooling module and changes in the charging current, facilitating precise thermal management control of the cooling module.

[0060] For example, a charging device supports continuous current regulation from 0 mA to 3000 mA. The kernel module sets a total of 11 control levels, ranging from 0 to 10. When establishing a linear mapping relationship, the 3000 mA current range is divided into 11 intervals, each interval corresponding to a current difference of 300 mA. Level 0 corresponds to 3000 mA, level 1 corresponds to 2700 mA, level 2 corresponds to 2400 mA, and so on, with level 10 corresponding to 0 mA. This forms a linear mapping relationship between the control level and the charging current. For every 1 increase in the control level, the corresponding charging current decreases by 300 mA.

[0061] In this embodiment, when the power supply controllability parameter indicates a discrete level adjustment range, the kernel module establishes a discrete mapping relationship between the control level and the charging level. Discrete level adjustment means that the charging device only supports a few preset fixed charging levels and cannot achieve continuous current adjustment; each level corresponds to a fixed charging current value. During the process of establishing the discrete mapping relationship, the kernel module sorts all the charging levels of the charging device in descending order of charging current, and maps the sorted levels to control levels one-to-one. The higher the charging current of the level, the lower the corresponding control level value, ensuring that the correspondence between the control level and the cooling control intensity remains consistent.

[0062] It should be noted that in the discrete mapping relationship, the total number of control levels is consistent with the number of charging levels supported by the charging device. This ensures that each charging level corresponds to a unique control level, and the control level output by the cooling module can be directly mapped to a fixed charging level, preventing control operations beyond the device's supported range. The establishment of the discrete mapping relationship ensures that this solution can be adapted to charging devices that only support fixed-level adjustment, expanding the solution's compatibility.

[0063] For example, a certain charging device only supports three fixed charging levels: fast charging, slow charging, and trickle charging, with corresponding charging currents of 3000 mA, 1500 mA, and 500 mA, respectively. The kernel module sorts the three levels according to the charging current from high to low: fast charging, slow charging, and trickle charging. When establishing the discrete mapping relationship, the total number of control levels is set to 3, with a level range of 0 to 2. Level 0 corresponds to the 3000 mA of fast charging, level 1 corresponds to the 1500 mA of slow charging, and level 2 corresponds to the 500 mA of trickle charging, forming a discrete mapping relationship between control levels and charging levels.

[0064] In this embodiment, when the power supply controllability parameter indicates a range that only supports charge / discharge enable control, the kernel module establishes a binary mapping relationship between control levels and charge / discharge enable states. Supporting only charge / discharge enable control means the charging device only supports two states: charging on and charging off. The charging current cannot be adjusted; cooling control can only be achieved by controlling the charging on and off states. During the establishment of this binary mapping relationship, the kernel module sets two control levels: level 0 corresponds to the charge / discharge enable on state, and level 1 corresponds to the charge / discharge enable off state, forming a binary mapping relationship between control levels and charge / discharge enable states. This ensures that the cooling module can control the charging device's on / off state by outputting different control levels.

[0065] It should be noted that the binary mapping relationship is only applicable to low-end charging devices that only support charge / discharge enable control. This mapping relationship ensures that the solution in this application is compatible with all charging devices that comply with power supply system specifications, and there will be no incompatibility issues due to limitations in device hardware capabilities. After the binary mapping relationship is established, the cooling module can directly control the opening and closing of the charging device by outputting a control level of 0 or 1, thereby achieving safety protection under extreme temperatures.

[0066] For example, the charging device of a certain embedded device only supports charge / discharge enable control and cannot adjust the charging current. Based on the hardware capability set of the device, the kernel module establishes a binary mapping relationship, setting a total of 2 control levels, with a level range of 0 to 1. Level 0 corresponds to the charging on state, and level 1 corresponds to the charging off state. When the cooling module outputs level 0, the charging device starts charging; when it outputs level 1, the charging device stops charging.

[0067] In this embodiment, after establishing the mapping relationship between control levels and corresponding parameter values, the real-time control level of the charging device is determined based on its current charging current. During this process, the kernel module reads the current charging power and charging voltage values ​​of the charging device through a standardized interface of the power supply system, and calculates the current charging current based on these values. After calculating the current charging current, the kernel module matches the control level corresponding to the current charging current based on the previously established mapping relationship. This level is the current real-time control level of the charging device.

[0068] It should be noted that the real-time control level is used to provide feedback on the current operating status of the charging device. Specifically, the control level reflects the current charging current and other operating conditions of the device. The cooling module can obtain the current cooling control status of the charging device by reading the real-time control level, forming a complete control closed loop. The real-time control level updates in real time as the charging device's operating status changes, with the update frequency matching the device's status sampling frequency to ensure that the feedback status information is consistent with the actual operating status of the device. The calculation process for the real-time control level is entirely completed in the kernel space, with a computation latency on the order of microseconds, eliminating any lag in status feedback.

[0069] For example, the mapping relationship between the control level and charging current of a certain charging device might be as follows: Level 0 corresponds to 3000 mA, Level 1 corresponds to 2700 mA, Level 2 corresponds to 2400 mA, and so on. The kernel module reads the current charging current of the device as 2400 mA, calculates the correspondence between the current charging current and the 2400 mA current value, and matches the corresponding control level as 2 based on the mapping relationship. Therefore, it can be determined that the current real-time control level of the charging device is 2.

[0070] In this embodiment, after determining the real-time control level, standardized attributes corresponding to the real-time control level are determined based on the power supply controllability parameters. These standardized attributes can be obtained from the sysfs file provided by the power supply system. For example, standardized attributes include whether constant_charge_current (constant current charging current setting), charge_enable (charge / discharge enable), current_max (maximum current limit), and pd_enable (PD fast charging switch) are supported. These standardized attributes can be associated with the control level of the charging control. Each function supported by the charging device in the standardized attributes is associated with its corresponding control level. When adjustment to the target control level is required, the cooling module can output a heat dissipation command to adjust to the target control level and its corresponding standardized attributes, achieving comprehensive charging control of different charging devices at different control levels by combining standardized attributes.

[0071] In this embodiment, after preparing the control levels, corresponding parameter values, real-time control levels, and standardized attributes, the control levels, parameter values, real-time control levels, and standardized attributes are encapsulated into a cooling device operation interface that can be called by the cooling module. The cooling module is a standardized subsystem in the Linux kernel used for system thermal management. This subsystem can only call cooling device operation interfaces that conform to its specifications to achieve unified control of various cooling devices. During the encapsulation process, the kernel module implements three standardized operation functions according to the interface specifications defined by the cooling module: a function to obtain the maximum control level, a function to obtain the current real-time control level, and a function to set the target control level. These three standardized operation functions will implement their corresponding functions based on the previously prepared control levels, parameter values, real-time control levels, and standardized attributes. After encapsulation, a complete cooling device operation interface is formed. In practical applications, those skilled in the art can set the control levels, parameter values, real-time control levels, and standardized attributes according to the standardization requirements of the cooling device operation interfaces that the cooling devices can call to achieve the encapsulation of the cooling device operation interface. This is a conventional technical method in the field and will not be elaborated further here.

[0072] It should be noted that the encapsulated cooling device operation interface fully complies with the standardized specifications of the cooling module. The cooling module can directly call this interface without needing to concern itself with the underlying details such as the hardware type and driver implementation of the charging device, thus achieving unified control of the charging device. During the encapsulation process, all hardware-related details are encapsulated within the interface, completely transparent to the cooling module, ensuring the interface's universality and compatibility. After the interface encapsulation is completed, the kernel module calls the registration interface provided by the cooling module to register the cooling device operation interface with the cooling module. After registration, the cooling module can recognize the cooling device and incorporate it into the system's thermal management system. This application uses the existing cooling module within Linux to control cooling devices (e.g., cooling fans) with control logic and functions similar to charging control. The charging device information is encapsulated into the cooling device operation interface, allowing the cooling module to directly call and generate heat dissipation commands. These heat dissipation commands are converted into charging control commands that the charging device driver IC (driver chip) can directly execute to control the charging device. This avoids the need to set up a separate driver in user space, the incompatibility of drivers, and the problems of having to modify the kernel architecture or make complex kernel program changes to achieve charging device charging control.

[0073] For example, the kernel module implements three standardized operation functions according to the cooling module's specifications. The function to retrieve the maximum control level returns the maximum value of the previously generated control level; the function to retrieve the current real-time control level returns the current real-time control level of the charging device; and the function to set the target control level matches the input target control level with the corresponding parameter values, writes these values ​​to the charging device using standardized attributes, and completes the setting of the charging parameters. These three functions together form the cooling device operation interface, which can be directly called by the cooling module.

[0074] In an optional implementation, the method further includes: S400: The control level, the parameter value corresponding to each control level, and the standardized attributes in the operation interface of the cooling device are respectively associated with multiple preset temperature threshold ranges of the corresponding battery device to form a preset association relationship.

[0075] In this embodiment, after the cooling device operation interface is encapsulated and registered, the control levels, parameter values ​​corresponding to each control level, and standardized attributes in the cooling device operation interface are associated with multiple preset temperature threshold ranges of the corresponding battery device to form preset association relationships. The preset temperature threshold ranges are multiple continuous temperature intervals pre-divided based on the safe operating temperature range of the battery device. Each temperature interval corresponds to a target control level. When the real-time temperature of the battery device is within a certain temperature interval, the cooling module outputs the target control level corresponding to that interval, thus achieving temperature-based charging control.

[0076] It should be noted that the division of preset temperature threshold ranges is based on the electrochemical characteristics of the battery device, ensuring that the control level corresponding to each temperature range guarantees the safe operation of the battery device within that range, while also reducing the aging rate of the battery device. Once the preset correlation is established, it will be stored in a dedicated data structure in the kernel space for the cooling module to access. The cooling module can directly determine the corresponding target control level based on the real-time temperature of the battery device according to the preset correlation. The division of preset temperature threshold ranges ensures that the intervals are continuous and non-overlapping, covering all possible operating temperature ranges of the battery device, and preventing situations where temperature values ​​cannot be matched to the corresponding intervals.

[0077] For example, a battery device may have a safe operating temperature range of 5°C to 50°C. Based on this range, five preset temperature threshold ranges are defined: below 5°C, between 5°C and 15°C, between 15°C and 40°C, between 40°C and 50°C, and above 50°C. When establishing preset correlations, the temperature range below 5°C corresponds to control level 10, the temperature range between 5°C and 15°C corresponds to control level 5, the temperature range between 15°C and 40°C corresponds to control level 0, the temperature range between 40°C and 50°C corresponds to control level 5, and the temperature range above 50°C corresponds to control level 10, thus forming a complete preset correlation.

[0078] In this embodiment, the cooling module incorporates a temperature hysteresis mechanism during the determination of the target preset temperature threshold range to prevent frequent switching of control levels when the battery temperature fluctuates near the threshold threshold. The temperature hysteresis mechanism is implemented by setting a fallback threshold. When the battery temperature rises and triggers a certain temperature threshold, the corresponding target control level is immediately switched; when the battery temperature drops, it needs to fall below a fallback threshold by a certain value before switching back to the previous control level. The fallback threshold value can be preset based on battery characteristics, typically set to 2 degrees Celsius to ensure that frequent control switching does not occur.

[0079] For example, the trigger threshold for high-temperature slow charging is set to 40 degrees Celsius, and the corresponding fallback threshold is set to 38 degrees Celsius. When the battery temperature rises to 40 degrees Celsius, the control level will be immediately switched to 5; when the battery temperature drops, it needs to drop below 38 degrees Celsius before switching back to control level 0. This avoids frequent switching of control levels when the temperature fluctuates around 40 degrees Celsius, which would cause repeated fluctuations in the charging current.

[0080] In alternative implementations, such as Figure 7As shown, the S200 method generates a heat dissipation command based on the real-time temperature of the battery device, including: S241: Determine the target preset temperature threshold range of the battery device based on the real-time temperature of the battery device.

[0081] S242: Determine the target control level corresponding to the target preset temperature threshold range based on the preset correlation relationship.

[0082] S243: Based on the real-time control level of the charging device, the target control level, the parameter value corresponding to the target control level, and the standardized attributes, a heat dissipation command is generated by the cooling module in the form of a control command for the cooling device.

[0083] In this embodiment, after the cooling device operation interface is registered, the cooling module in the Linux system calls the cooling device operation interface to generate a heat dissipation command based on the real-time temperature of the battery device. During the generation of the heat dissipation command, the target preset temperature threshold range of the battery device is first determined based on its real-time temperature. The real-time temperature of the battery device is obtained in real-time through the temperature sampling node corresponding to the battery device. The temperature sampling node reports the cell temperature of the battery device to the cooling module in real-time. The cooling module matches the reported real-time temperature value to the preset temperature threshold range in which that temperature value falls; this range is the target preset temperature threshold range.

[0084] It should be noted that the temperature sampling process for the battery device is completed by the standardized temperature sampling mechanism of the cooling module. The sampling frequency can be adjusted based on system requirements to ensure timely acquisition of temperature changes in the battery device and trigger corresponding cooling control. The temperature sampling process is entirely based on the standardized thermal management mechanism of the Linux kernel, requiring no additional development of dedicated temperature sampling logic. The association between the temperature sampling node and the battery device is automatically matched based on the previously established association between the charging device and the battery device, ensuring that the sampled temperature data corresponds exactly to the controlled battery device.

[0085] For example, a preset temperature threshold range for a battery device includes five intervals: below 5 degrees Celsius, 5 to 15 degrees Celsius, 15 to 40 degrees Celsius, 40 to 50 degrees Celsius, and above 50 degrees Celsius. If the cooling module obtains a real-time temperature of 42 degrees Celsius for the battery device, and matches this temperature value to the 40 to 50 degree Celsius range, then the target preset temperature threshold range can be determined to be between 40 and 50 degrees Celsius.

[0086] In this embodiment, after determining the target preset temperature threshold range, a target control level corresponding to the target preset temperature threshold range is determined based on a preset correlation. The target control level is the control level that the cooling module expects the charging device to operate at, used to achieve charging control within the corresponding temperature range. During the process of determining the target control level, the cooling module reads the preset correlation and searches for the control level corresponding to the target preset temperature threshold range; this level is the target control level.

[0087] It should be noted that in the preset association relationships, each preset temperature threshold range corresponds to only one unique target control level. This ensures that the cooling module can determine a unique control target based on the temperature value, preventing conflicts in control logic. The value of the target control level is determined based on the degree of impact of the temperature range on the battery. The further the temperature deviates from the battery's optimal operating temperature range, the higher the corresponding target control level value, and the stronger the cooling control.

[0088] For example, in the preset association relationship, the control level corresponding to the temperature range of 40 to 50 degrees Celsius is 5. After the cooling module determines that the target preset temperature threshold range is 40 to 50 degrees Celsius, it can read the preset association relationship and determine that the corresponding target control level is 5.

[0089] In this embodiment, after determining the target control level, a heat dissipation command is generated based on the real-time control level of the charging device, the target control level, the parameter values ​​corresponding to the target control level, and standardized attributes. This command is output by the cooling module to control the cooling device. During the generation of the heat dissipation command, the cooling module compares the real-time control level of the charging device with the target control level. If the two values ​​are the same, no new heat dissipation command is generated, and the current operating state of the charging device is maintained. If the two values ​​are different, a heat dissipation command containing the target control level is generated and sent to the charging device through the cooling device operation interface to complete the adjustment of the charging parameters.

[0090] It should be noted that the process of issuing heat dissipation commands is completed entirely through standardized calls between the cooling module and the cooling equipment's operating interface, without any additional intermediate steps. The command issuance latency is at the microsecond level, enabling rapid response to temperature changes. Simultaneously, during command issuance, the target control level value is validated to ensure it falls within the range of 0 to the maximum control level, preventing control operations beyond the device's capabilities. The generation and issuance of heat dissipation commands are entirely completed in kernel space, without user-space involvement, ensuring the real-time performance and reliability of the control process.

[0091] For example, if the current real-time control level of the charging device is 0, and the target control level determined by the cooling module is 5, since the two values ​​are different, the cooling module will generate a heat dissipation command containing the target control level of 5. Through the setting target control level function in the cooling device operation interface, the heat dissipation command will be sent to the charging device. After receiving the command, the charging device will adjust the charging parameters to the values ​​corresponding to control level 5, thus completing the charging control.

[0092] In this embodiment, upon receiving a heat dissipation command from the cooling module, the heat dissipation command is converted into a charging control command and sent to the driver chip of the charging device. The driver chip then adjusts the operating parameters of the charging device based on the charging control command. During the conversion process, the target control level contained in the heat dissipation command is parsed. Based on a preset mapping relationship, the parameter value corresponding to the target control level and the standardized attribute corresponding to that parameter value are matched. After matching, the parameter value is converted into a charging control command recognizable by the driver chip according to the format required by the standardized attribute. This charging control command is then sent to the driver chip of the charging device through the standardized interface of the power supply system.

[0093] It's important to note that the charging control commands are hardware control commands that the driver chip can directly execute. The format and content of these commands fully conform to the driver chip's specifications. Upon receiving the command, the driver chip directly executes the corresponding hardware operation to adjust the charging device's operating parameters. The entire conversion and transmission process is completed based on the standardized interface of the Linux kernel, eliminating the need to develop dedicated command conversion logic for specific driver chips, thus ensuring the solution's versatility. After the command is sent, the kernel module reads the charging device's operating status to confirm whether the parameter adjustments have taken effect, forming a closed-loop control system.

[0094] For example, the cooling device's operating interface receives a heat dissipation command containing a target control level of 5. After parsing, it determines the target control level is 5 and, based on the mapping relationship, matches the corresponding parameter value to 1500 mA. The corresponding standardized attribute is a constant current charging current setting file. The cooling device's operating interface converts 1500 mA into a microamplitude (µA) value, generates the corresponding charging control command, and sends it to the charging device's driver chip through the standardized interface of the power supply system. Upon receiving the command, the driver chip adjusts the charging current of the charging device to 1500 mA, completing the adjustment of the operating parameters.

[0095] In an optional implementation, in response to a device deregistration request from the charging device driver chip, the cooling device operation interface is deleted, related data within the Linux kernel is deleted, and the occupied Linux kernel memory is released.

[0096] In this embodiment, the kernel module responds to the device deregistration request from the charging device's driver chip by deleting the cooling device's operating interface, deleting related data within the Linux kernel, and releasing the occupied Linux kernel memory. The device deregistration request is sent by the charging device's driver to the power supply system during device removal, notifying the kernel that the device has been removed from the system and can no longer provide service. The kernel module listens for the device deregistration request through previously registered event listener callbacks. Upon receiving the request, it first deletes the cooling device's operating interface corresponding to the charging device and deregisters the cooling device with the cooling module, ensuring that the cooling module will not continue to issue control commands to the removed device.

[0097] It should be noted that the process of deleting the cooling device operation interface will be completed in accordance with Linux kernel specifications, ensuring that no invalid operation function entries remain in the kernel after the interface is deregistered, thus avoiding system anomalies. After the interface is deleted, the cooling module will automatically remove the relevant information of the cooling device, without affecting the normal operation of other cooling devices in the system. For systems containing multiple sets of charging and discharging devices, only the cooling device operation interface corresponding to the deregistered device will be deleted; other normally operating devices will not be affected.

[0098] In this embodiment, after deleting the cooling device operation interface, the kernel module deletes all data related to the charging device stored in the Linux kernel, including the device's hardware capability set, control level mapping relationship, preset association relationship, device association information, etc. After the data deletion is completed, the kernel module releases all Linux kernel memory occupied by the device and returns the occupied memory space to the kernel memory management system to ensure that no memory leak occurs.

[0099] It should be noted that the entire resource cleanup process strictly adheres to Linux kernel memory management specifications, ensuring that all allocated kernel memory is completely released and will not affect the stable operation of the system. Furthermore, the resource cleanup process only targets deregistered charging devices and will not affect the control functions of other normally operating charging devices in the system. If the device is subsequently reconnected to the system, the driver will re-register the device with the power supply system, and the kernel module will re-execute the complete process of device identification, capability set detection, and interface generation to restore control over the device.

[0100] For example, when a charging device is hot-removed from the system, the corresponding driver chip sends a device deregistration request to the power supply system. Upon receiving this request, the kernel module first deregisters the corresponding cooling device operation interface with the cooling module and deletes all operation functions associated with that interface. Then, the kernel module deletes the device's hardware capability set, control level mapping, and other related data stored in the kernel. Finally, it releases all kernel memory occupied by the device, completing the entire resource cleanup process.

[0101] In this embodiment, the kernel module incorporates a hardware availability watchdog mechanism to handle abnormal situations of the charging device. The watchdog mechanism checks the charging device's response to control commands at fixed time intervals. If multiple consecutive command writes fail to elicit a response, or if the device state experiences an abnormal jump, a degradation process is automatically executed. During the degradation process, the kernel module first deregisters the cooling device's operation interface with the cooling module, suspending the cooling control function. Then, it restores all parameters of the charging device to the system's native default state, ensuring that the device's basic charging function is unaffected. Simultaneously, it outputs the corresponding exception information through the kernel log interface for subsequent troubleshooting.

[0102] In a specific example, when the charging device is deregistered, the command `rmmod generic_charging_cooling.ko` is executed, and the kernel module automatically performs the following operations: 1. Deregisters the generic_charging_cooling cooling device and unbinds it from multiple preset temperature threshold ranges (thermal_zone0); 2. Restores the charging current, PD fast charging switch, and charge / discharge enable state of the RT9466-charger to the original system configuration before the module was loaded; 3. Releases all kernel resources, and the system is completely restored to its initial state without any residual configuration or modifications to the original driver.

[0103] It should be noted that the watchdog timer's detection interval can be adjusted based on system requirements, typically set to 100 milliseconds to ensure timely detection of device anomalies and prevent control failures. The degradation process ensures that even in the event of a device malfunction, the system's stable operation and the device's basic charging functions will not be affected. Once the anomaly is resolved, the kernel module will automatically re-execute the device initialization process and restore cooling control functions without requiring manual user intervention.

[0104] In this embodiment, a Linux system is also provided, including a kernel module. This kernel module is configured to traverse the device registration list of the power supply system, identify charging devices and battery devices, and associate them; generate a cooling device operation interface corresponding to the charging device; call the cooling device operation interface through the cooling module in the Linux system to generate a heat dissipation command based on the real-time temperature of the battery device; convert the heat dissipation command into a charging control command and send it to the driver chip of the charging device, so that the driver chip adjusts the operating parameters of the charging device based on the charging control command. All configurations and functional implementations of this kernel module correspond completely to the content in the above method embodiments, and will not be repeated here. This kernel module is provided in the form of a loadable kernel module, which can be dynamically loaded into the kernel space of the Linux system to run without modifying the system kernel source code or the original device driver, thus possessing good compatibility and deployability.

[0105] The following specific example further illustrates this application. In this example, the Linux operating system kernel version is 4.19, the charging device uses the RT9466 charging IC, and the battery is a ternary lithium battery with a rated capacity of 5000 mAh. The charging driver for this device has been registered with the Linux power supply system, conforms to the kernel's standardized specifications, and has not undergone any customized modifications.

[0106] First, the kernel module is compiled and deployed. Based on the kernel development environment provided by this Linux system and the corresponding kernel header files, the kernel module code is written and compiled using the Makefile compilation framework provided by the kernel to obtain the generic_charging_cooling.ko kernel module file. After compilation, the kernel module is loaded into the system kernel space using the Linux system's insmod command, completing the pre-installation of the kernel module. During the module loading process, the system kernel performs a validity check on the module. After the check passes, the module is initialized in the kernel space, creating the corresponding kernel data structures to prepare for subsequent device identification and control.

[0107] After module initialization, the kernel module begins traversing the device registration list of the power supply system. Using the device traversal interface provided by the power supply system, the kernel module iterates through all registered devices in the system, obtaining basic information for each device. During traversal, the kernel module reads the device type attribute of each device. It finds that the device rt9466_charger has a power input attribute and identifies it as a charging device; it finds that the device rt9466_battery has a battery storage attribute and identifies it as a battery device. Next, the kernel module performs device association. It reads the hardware topology information of the devices and finds that rt9466_charger and rt9466_battery are connected to the same I2C bus channel 0, belonging to the same power supply link. It establishes an association between the two, binding them as a charging / discharging device combination.

[0108] Then, the kernel module accesses the sysfs file directory corresponding to rt9466_charger through the standardized kernel exposure interface provided by the electronic system, reads all sysfs files in the directory, and obtains the preset attribute file of the charging device. The read attribute file includes constant_charge_current, charge_enable, current_max, pd_enable, etc., which correspond to functions such as constant current charging current setting, charge / discharge enable control, maximum charging current reading, and fast charging protocol switch, respectively.

[0109] The kernel module verifies the readability and parameter range of each attribute file. The verification reveals that the `constant_charge_current` file is writable, with a parameter range of 0 mA to 3000 mA and a step precision of 100 mA; the `charge_enable` file is writable, with a parameter value of 0 or 1; the `current_max` file is readable, with a maximum reading charging current of 3000 mA; and the `pd_enable` file is writable, with a parameter value of 0 or 1. Based on the verification results, the kernel module compiles the hardware capability set of the charging device, including three controllable power supply capabilities: charging current adjustment, charge / discharge enable control, and fast charging protocol control, as well as the adjustable range for each parameter.

[0110] This charging device supports continuous current regulation. The kernel module establishes a linear mapping relationship between control levels and charging current, setting a total of 11 control levels ranging from 0 to 10. In the linear mapping relationship, the charging current corresponding to level 0 is 3000 mA, the charging current corresponding to level 10 is 0 mA, the current difference between each adjacent level is 300 mA, and the current values ​​corresponding to all levels are within the parameter range of 0 to 3000 mA.

[0111] The kernel module reads the current charging current of the charging device as 3000 mA through the standardized interface of the power supply system. Based on a linear mapping relationship, it matches the corresponding control level as 0, thus determining that the current real-time control level of the device is 0. Simultaneously, based on the power supply controllability parameters, it determines the standardized attributes corresponding to each control level. The standardized attribute for charging current adjustment is the `constant_charge_current` file, the standardized attribute for charge / discharge enable control is the `charge_enable` file, and the standardized attribute for fast charging protocol control is the `pd_enable` file.

[0112] Next, the cooling device operation interface is encapsulated. Following the standardized specifications of the cooling module, the kernel module implements three standardized operation functions: `get_max_state` returns the maximum control level of 10, `get_cur_state` returns the current real-time control level of the device, and `set_cur_state` matches the corresponding parameter value based on the input target control level and writes it to the charging device through standardized attributes. After these three functions are encapsulated, a complete cooling device operation interface is formed. The kernel module calls the cooling module's registration interface to register this cooling device operation interface with the cooling module, naming the registered device `generic_charging_cooling`. After registration, the cooling module can directly call this interface to control the charging device.

[0113] Next, preset associations are established. Based on the safe operating temperature range of the ternary lithium battery in this device, five preset temperature threshold ranges are defined: below 5 degrees Celsius, 5 to 15 degrees Celsius, 15 to 40 degrees Celsius, 40 to 50 degrees Celsius, and above 50 degrees Celsius. When establishing these preset associations, the temperature range below 5 degrees Celsius corresponds to control level 10, the range from 5 to 15 degrees Celsius corresponds to control level 5, the range from 15 to 40 degrees Celsius corresponds to control level 0, the range from 40 to 50 degrees Celsius corresponds to control level 5, and the range above 50 degrees Celsius corresponds to control level 10. Simultaneously, when the control level is greater than or equal to 5, the fast charging protocol is automatically disabled, and the pd_enable file is set to 0. After the preset associations are established, they are stored in a dedicated data structure in the kernel space for the cooling module to access. A 2-degree Celsius fallback threshold is also set for each temperature threshold, incorporating a temperature hysteresis mechanism to avoid frequent switching of control levels.

[0114] Next, real-time temperature monitoring and heat dissipation command generation are performed. The device is connected to the charger to begin charging. The initial battery temperature is 25 degrees Celsius. The cooling module obtains the real-time temperature of 25 degrees Celsius through the corresponding temperature sampling node of the battery. It matches this temperature to the target preset temperature threshold range of 15 to 40 degrees Celsius. Based on the preset correlation, the corresponding target control level is determined to be 0. The cooling module compares the real-time control level 0 with the target control level 0; since the values ​​are the same, no new heat dissipation command is generated, and the current charging state is maintained. The charging current is 3000 mA, and the fast charging protocol is enabled normally.

[0115] When the device is operating under high load, the battery temperature gradually rises to 41 degrees Celsius. The cooling module obtains the real-time temperature as 41 degrees Celsius and matches it to the target preset temperature threshold range of 40 to 50 degrees Celsius. Based on the preset correlation, the corresponding target control level is determined to be 5. The cooling module compares the real-time control level 0 with the target control level 5. Since the two values ​​are different, a heat dissipation command containing the target control level 5 is generated and issued through the cooling device operation interface.

[0116] After receiving the heat dissipation command, the cooling device's operation interface parses it to obtain a target control level of 5. Based on a linear mapping relationship, it matches the corresponding charging current as 1500 mA, with the corresponding standardized attribute being the `constant_charge_current` file. Simultaneously, it detects that the target control level of 5 meets the conditions for disabling the fast charging protocol, and matches the corresponding standardized attribute as the `pd_enable` file. The cooling device's operation interface converts the 1500 mA to a value in microamps, generates the corresponding charging control command, and sends it to the RT9466 driver chip through the power supply system's standardized interface. Simultaneously, it generates a charging control command to disable the fast charging protocol and sends it to the driver chip. Upon receiving the command, the driver chip adjusts the charging current to 1500 mA, disables the PD fast charging protocol, and completes the adjustment of the charging operation parameters.

[0117] After parameter adjustment, the kernel module rereads the current charging current of the charging device as 1500 mA, updates the real-time control level to 5, and feeds back the current operating status to the cooling module, forming a complete control closed loop. As the charging current decreases, the battery temperature gradually drops. When the temperature drops to 37 degrees Celsius, it reaches the 38-degree Celsius fallback threshold. The cooling module matches this temperature to the range of 15 to 40 degrees Celsius, determines the target control level to 0, generates the corresponding heat dissipation command, gradually restores the charging current to 3000 mA, and restarts the fast charging protocol.

[0118] When the battery temperature rises to 51 degrees Celsius, the cooling module obtains the real-time temperature as 51 degrees Celsius, determines that this temperature falls within the range above 50 degrees Celsius, sets the target control level to 10, and generates and issues the corresponding heat dissipation command. Upon receiving the command, the cooling device's operation interface parses it to obtain the target control level of 10, matches it to the corresponding charging current of 0 mA, and simultaneously matches the standardized attributes of charge / discharge enable. It then generates a charging control command to shut down charging and sends it to the driver chip. Upon receiving the command, the driver chip disables charging enable and stops charging to prevent the risk of thermal runaway of the battery.

[0119] When a user needs to remove a kernel module, they can use the `rmmod` command in Linux to uninstall the `generic_charging_cooling.ko` kernel module. During the uninstallation process, the module first unregisters all registered cooling device operation interfaces from the cooling module and deletes all corresponding control logic. Then, it deletes all device-related data stored in the kernel, including hardware capability sets, mappings, and associations. Finally, it releases all occupied kernel memory, completely restoring the system to its original state before the module was loaded, without affecting the system's original functionality.

[0120] Obviously, the above embodiments of this disclosure are merely examples for clearly illustrating this disclosure, and are not intended to limit the implementation of this disclosure. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all implementation methods here. Any obvious variations or modifications derived from the technical solutions of this disclosure are still within the protection scope of this disclosure.

Claims

1. A charging control method based on a Linux system kernel module, characterized in that, include: The system uses a pre-installed kernel module in Linux to traverse the device registration list of the power supply system, identify charging devices and battery devices, and associate charging devices and battery devices. A cooling device operation interface corresponding to the charging device is generated, and the cooling module in the Linux system calls the cooling device operation interface to generate a heat dissipation command based on the real-time temperature of the battery device. The heat dissipation command is converted into a charging control command and sent to the driver chip of the charging device so that the driver chip adjusts the operating parameters of the charging device based on the charging control command.

2. The method according to claim 1, characterized in that, This further includes traversing the device registry list of the power supply system via a kernel module pre-installed in the Linux system: The generic_charging_cooling.ko kernel module for charging control is compiled, and the generic_charging_cooling.ko kernel module is a loadable kernel module supported by the Linux system; The generic_charging_cooling.ko kernel module is pre-installed on the Linux system using the insmod command.

3. The method according to claim 1, characterized in that, The operation interface for generating the cooling device corresponding to the charging device includes: Obtain the preset attribute file of the charging device; The hardware capability set of the charging device is determined based on the preset attribute file. The hardware capability set includes the power supply controllability parameters of the charging device and their parameter ranges. The cooling device operation interface corresponding to the charging device is generated based on the hardware capability set.

4. The method according to claim 3, characterized in that, The method for obtaining the preset attribute file of the charging device includes: The sysfs file of the charging device is obtained through the standardized kernel exposure interface of the power supply system, and the preset attribute file is obtained.

5. The method according to claim 3, characterized in that, The step of generating the cooling device operation interface corresponding to the charging device based on the hardware capability set includes: Based on the power supply controllability parameters and parameter range of the charging device, a corresponding control level and parameter values ​​corresponding to the control level are generated, wherein the range of parameter values ​​of the control level is within the parameter range; The current real-time control level of the charging device is determined based on the current charging current of the charging device, and the standardized attributes corresponding to the real-time control level are determined based on the power supply controllability parameters. The control level, the parameter values ​​corresponding to each control level, the real-time control level, and the standardized attributes are encapsulated into a cooling equipment operation interface that can be called by the cooling module.

6. The method according to claim 5, characterized in that, The generation of the corresponding control level and the corresponding parameter value based on the power supply controllability parameters and parameter range of the charging device includes: When the power supply controllability parameter supports continuous adjustment within the parameter range, a linear mapping relationship between the control level and the charging current is established. When the power supply controllability parameter supports discrete level adjustment within the parameter range, a discrete mapping relationship between the control level and the charging level is established. When the power supply controllability parameter is set to only support charge and discharge enable control within the parameter range, a binary mapping relationship between the control level and the charge and discharge enable state is established.

7. The method according to claim 5, characterized in that, Further includes: The control levels, parameter values ​​corresponding to each control level, and standardized attributes in the operation interface of the cooling equipment are respectively associated with multiple preset temperature threshold ranges of the corresponding battery equipment to form a preset association relationship.

8. The method according to claim 7, characterized in that, The heat dissipation command based on the real-time temperature of the battery device includes: The target preset temperature threshold range of the battery device is determined based on the real-time temperature of the battery device. The target control level corresponding to the target preset temperature threshold range is determined based on the preset correlation relationship; Based on the real-time control level of the charging device, the target control level, the parameter values ​​corresponding to the target control level, and standardized attributes, a heat dissipation command is generated from the cooling module to control the cooling device.

9. The method according to claim 1, characterized in that, Further includes: In response to the device deregistration request from the charging device driver chip, the cooling device operation interface is deleted, related data within the Linux kernel is deleted, and the occupied Linux kernel memory is released.

10. A Linux system, characterized in that, The system includes a kernel module configured to traverse the device registration list of the power supply system, identify charging devices and battery devices, and associate charging devices and battery devices; generate a cooling device operation interface corresponding to the charging device, call the cooling device operation interface through the cooling module in the Linux system, generate a heat dissipation command based on the real-time temperature of the battery device; convert the heat dissipation command into a charging control command and send it to the driver chip of the charging device so that the driver chip adjusts the operating parameters of the charging device based on the charging control command.

Images