drivers/platform/arm64/huawei-gaokun-ec.c
Source file repositories/reference/linux-study-clean/drivers/platform/arm64/huawei-gaokun-ec.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/platform/arm64/huawei-gaokun-ec.c- Extension
.c- Size
- 19605 bytes
- Lines
- 828
- Domain
- Driver Families
- Bucket
- drivers/platform
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/auxiliary_bus.hlinux/cleanup.hlinux/delay.hlinux/device.hlinux/hwmon.hlinux/hwmon-sysfs.hlinux/i2c.hlinux/input.hlinux/notifier.hlinux/module.hlinux/mutex.hlinux/platform_data/huawei-gaokun-ec.h
Detected Declarations
struct gaokun_ecenum gaokun_ec_smart_charge_cmdenum gaokun_ec_ucsi_cmdfunction refill_reqfunction refill_req_bytefunction extr_respfunction extr_resp_bytefunction gaokun_ec_requestfunction ECCDfunction gaokun_ec_writefunction gaokun_ec_read_bytefunction gaokun_ec_register_notifyfunction gaokun_ec_register_notifyfunction gaokun_ec_psy_multi_readfunction gaokun_ec_psy_get_smart_chargefunction validate_battery_threshold_rangefunction gaokun_ec_psy_set_smart_chargefunction gaokun_ec_psy_get_smart_charge_enablefunction gaokun_ec_psy_set_smart_charge_enablefunction MSGIfunction MSGOfunction datafunction notificationsfunction gaokun_ec_get_fn_lockfunction gaokun_ec_set_fn_lockfunction fn_lock_showfunction fn_lock_storefunction gaokun_ec_get_tempfunction gaokun_ec_hwmon_is_visiblefunction gaokun_ec_hwmon_readfunction gaokun_ec_suspendfunction gaokun_ec_resumefunction gaokun_aux_releasefunction gaokun_aux_removefunction gaokun_aux_initfunction gaokun_ec_irq_handlerfunction gaokun_ec_probeexport gaokun_ec_readexport gaokun_ec_writeexport gaokun_ec_read_byteexport gaokun_ec_register_notifyexport gaokun_ec_unregister_notifyexport gaokun_ec_psy_multi_readexport gaokun_ec_psy_get_smart_chargeexport gaokun_ec_psy_set_smart_chargeexport gaokun_ec_psy_get_smart_charge_enableexport gaokun_ec_psy_set_smart_charge_enableexport gaokun_ec_ucsi_read
Annotated Snippet
struct gaokun_ec {
struct i2c_client *client;
struct mutex lock; /* EC transaction lock */
struct blocking_notifier_head notifier_list;
struct device *hwmon_dev;
struct input_dev *idev;
bool suspended;
};
static int gaokun_ec_request(struct gaokun_ec *ec, const u8 *req,
size_t resp_len, u8 *resp)
{
struct i2c_client *client = ec->client;
struct i2c_msg msgs[] = {
{
.addr = client->addr,
.flags = client->flags,
.len = REQ_LEN(req),
.buf = (void *)req,
}, {
.addr = client->addr,
.flags = client->flags | I2C_M_RD,
.len = resp_len,
.buf = resp,
},
};
int ret;
guard(mutex)(&ec->lock);
ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
if (ret != ARRAY_SIZE(msgs)) {
dev_err(&client->dev, "I2C transfer error %d\n", ret);
goto out_after_break;
}
ret = *resp;
if (ret)
dev_err(&client->dev, "EC transaction error %d\n", ret);
out_after_break:
usleep_range(2000, 2500); /* have a break, ACPI did this */
return ret;
}
/* -------------------------------------------------------------------------- */
/* Common API */
/**
* gaokun_ec_read - Read from EC
* @ec: The gaokun_ec structure
* @req: The sequence to request
* @resp_len: The size to read
* @resp: The buffer to store response sequence
*
* This function is used to read data after writing a magic sequence to EC.
* All EC operations depend on this function.
*
* Huawei uses magic sequences everywhere to complete various functions, all
* these sequences are passed to ECCD(a ACPI method which is quiet similar
* to gaokun_ec_request), there is no good abstraction to generalize these
* sequences, so just wrap it for now. Almost all magic sequences are kept
* in this file.
*
* Return: 0 on success or negative error code.
*/
int gaokun_ec_read(struct gaokun_ec *ec, const u8 *req,
size_t resp_len, u8 *resp)
{
return gaokun_ec_request(ec, req, resp_len, resp);
}
EXPORT_SYMBOL_GPL(gaokun_ec_read);
/**
* gaokun_ec_write - Write to EC
* @ec: The gaokun_ec structure
* @req: The sequence to request
*
* This function has no big difference from gaokun_ec_read. When caller care
* only write status and no actual data are returned, then use it.
*
* Return: 0 on success or negative error code.
*/
int gaokun_ec_write(struct gaokun_ec *ec, const u8 *req)
{
u8 ec_resp[] = MKRESP(0);
return gaokun_ec_request(ec, req, sizeof(ec_resp), ec_resp);
}
EXPORT_SYMBOL_GPL(gaokun_ec_write);
Annotation
- Immediate include surface: `linux/auxiliary_bus.h`, `linux/cleanup.h`, `linux/delay.h`, `linux/device.h`, `linux/hwmon.h`, `linux/hwmon-sysfs.h`, `linux/i2c.h`, `linux/input.h`.
- Detected declarations: `struct gaokun_ec`, `enum gaokun_ec_smart_charge_cmd`, `enum gaokun_ec_ucsi_cmd`, `function refill_req`, `function refill_req_byte`, `function extr_resp`, `function extr_resp_byte`, `function gaokun_ec_request`, `function ECCD`, `function gaokun_ec_write`.
- Atlas domain: Driver Families / drivers/platform.
- Implementation status: integration implementation candidate.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.