Host OS-EC Kernel Driver for Cross-Platform Communication Paths
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems lack a platform-agnostic communication mechanism between host Operating Systems (OS) and Embedded Controllers (EC) in Information Handling Systems (IHS), leading to inefficiencies and inconsistencies across different processor architectures.
Innovation Solution
A kernel driver translates messages between host OS applications and ECs using a common API, selecting appropriate data transfer paths based on processor type, such as CISC or RISC architectures, and employing interfaces like I2C, I3C, SPI, or eSPI, with security architectures like TRUSTZONE for secure communication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a platform-specific communication mechanism is used between host OS and EC, then communication reliability is improved, but adaptability across different processor architectures deteriorates
Solution Approach 1:
The patent implements a universal communication framework where the EC can be accessed through multiple standardized interfaces (I2C, SPI, eSPI, USB) and the host OS can communicate through different paths (ACPI, device drivers, direct memory access) depending on the processor architecture. This allows the same EC to work reliably across CISC, RISC, and other processor types without requiring architecture-specific EC implementations.
Solution Approach 2:
The patent introduces intermediary layers including device drivers, ACPI interfaces, and standardized protocols that mediate between the host OS and EC. These intermediaries translate and adapt communication between different architectures, ensuring reliable EC communication while maintaining broad platform compatibility through abstraction layers.
2Adaptability or versatility
If multiple data transfer paths are supported for different processor types, then adaptability is improved, but system complexity deteriorates
Solution Approach 1:
The patent segments the communication system into distinct, modular components: processor-specific path selection logic, standardized EC interfaces (I2C, SPI, eSPI, USB), and common communication protocols. Each segment handles specific functionality independently, allowing the system to support multiple processor types without creating a monolithic complex system.
Solution Approach 2:
The patent uses parameter changes to adapt the communication path based on processor architecture detection. The system automatically selects appropriate communication parameters (interface type, protocol, data width) based on the detected processor type, simplifying the user experience while supporting diverse architectures through configurable parameters.
3Productivity
If architecture-specific communication paths are used, then communication efficiency is improved, but ease of operation deteriorates
Solution Approach 1:
The patent introduces intermediary abstraction layers including standardized device drivers and ACPI interfaces that shield developers from architecture-specific communication details. Developers interact with a unified EC interface while the intermediaries automatically handle the efficient architecture-specific communication paths, maintaining both efficiency and ease of operation.
Solution Approach 2:
The patent implements self-service through automatic processor architecture detection and adaptive path selection. The system automatically identifies the processor type and configures the appropriate communication path without requiring manual intervention or complex configuration by the operator, achieving both efficiency and ease of use.
Data Source
AI summary
Systems and methods for platform-agnostic communications between a host Operating System (OS) and an Embedded Controller (EC) are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to: receive, at a kernel driver of a host OS, a message from a host OS application for distribution to an EC; translate the message, by the kernel driver, into an Application Programming Interface (API) call corresponding to a selected one of a plurality of data transfer paths between the kernel driver and the EC, based, at least in part, upon a type of the processor; and transmit the API call by the kernel driver to the EC via the selected data transfer path.