drivers/i2c/busses/i2c-cht-wc.c
Source file repositories/reference/linux-study-clean/drivers/i2c/busses/i2c-cht-wc.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/i2c/busses/i2c-cht-wc.c- Extension
.c- Size
- 16805 bytes
- Lines
- 560
- Domain
- Driver Families
- Bucket
- drivers/i2c
- Inferred role
- Driver Families: implementation source
- Status
- source 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- 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/acpi.hlinux/completion.hlinux/delay.hlinux/i2c.hlinux/interrupt.hlinux/irq.hlinux/irqdomain.hlinux/mfd/intel_soc_pmic.hlinux/module.hlinux/platform_device.hlinux/power/bq24190_charger.hlinux/power/bq25890_charger.hlinux/slab.h
Detected Declarations
struct cht_wc_i2c_adapfunction cht_wc_i2c_adap_thread_handlerfunction cht_wc_i2c_adap_funcfunction cht_wc_i2c_adap_smbus_xferfunction cht_wc_i2c_adap_lock_busfunction cht_wc_i2c_adap_trylock_busfunction cht_wc_i2c_adap_unlock_busfunction cht_wc_i2c_irq_lockfunction cht_wc_i2c_irq_sync_unlockfunction cht_wc_i2c_irq_enablefunction cht_wc_i2c_irq_disablefunction cht_wc_i2c_adap_i2c_probefunction cht_wc_i2c_adap_i2c_remove
Annotated Snippet
struct cht_wc_i2c_adap {
struct i2c_adapter adapter;
wait_queue_head_t wait;
struct irq_chip irqchip;
struct mutex adap_lock;
struct mutex irqchip_lock;
struct regmap *regmap;
struct irq_domain *irq_domain;
struct i2c_client *client;
int client_irq;
u8 irq_mask;
u8 old_irq_mask;
int read_data;
bool io_error;
bool done;
};
static irqreturn_t cht_wc_i2c_adap_thread_handler(int id, void *data)
{
struct cht_wc_i2c_adap *adap = data;
int ret, reg;
mutex_lock(&adap->adap_lock);
/* Read IRQs */
ret = regmap_read(adap->regmap, CHT_WC_EXTCHGRIRQ, ®);
if (ret) {
dev_err(&adap->adapter.dev, "Error reading extchgrirq reg\n");
mutex_unlock(&adap->adap_lock);
return IRQ_NONE;
}
reg &= ~adap->irq_mask;
/* Reads must be acked after reading the received data. */
ret = regmap_read(adap->regmap, CHT_WC_I2C_RDDATA, &adap->read_data);
if (ret)
adap->io_error = true;
/*
* Immediately ack IRQs, so that if new IRQs arrives while we're
* handling the previous ones our irq will re-trigger when we're done.
*/
ret = regmap_write(adap->regmap, CHT_WC_EXTCHGRIRQ, reg);
if (ret)
dev_err(&adap->adapter.dev, "Error writing extchgrirq reg\n");
if (reg & CHT_WC_EXTCHGRIRQ_ADAP_IRQMASK) {
adap->io_error |= !!(reg & CHT_WC_EXTCHGRIRQ_NACK_IRQ);
adap->done = true;
}
mutex_unlock(&adap->adap_lock);
if (reg & CHT_WC_EXTCHGRIRQ_ADAP_IRQMASK)
wake_up(&adap->wait);
/*
* Do NOT use handle_nested_irq here, the client irq handler will
* likely want to do i2c transfers and the i2c controller uses this
* interrupt handler as well, so running the client irq handler from
* this thread will cause things to lock up.
*/
if (reg & CHT_WC_EXTCHGRIRQ_CLIENT_IRQ)
generic_handle_irq_safe(adap->client_irq);
return IRQ_HANDLED;
}
static u32 cht_wc_i2c_adap_func(struct i2c_adapter *adap)
{
/* This i2c adapter only supports SMBUS byte transfers */
return I2C_FUNC_SMBUS_BYTE_DATA;
}
static int cht_wc_i2c_adap_smbus_xfer(struct i2c_adapter *_adap, u16 addr,
unsigned short flags, char read_write,
u8 command, int size,
union i2c_smbus_data *data)
{
struct cht_wc_i2c_adap *adap = i2c_get_adapdata(_adap);
int ret;
mutex_lock(&adap->adap_lock);
adap->io_error = false;
adap->done = false;
mutex_unlock(&adap->adap_lock);
ret = regmap_write(adap->regmap, CHT_WC_I2C_CLIENT_ADDR, addr);
if (ret)
Annotation
- Immediate include surface: `linux/acpi.h`, `linux/completion.h`, `linux/delay.h`, `linux/i2c.h`, `linux/interrupt.h`, `linux/irq.h`, `linux/irqdomain.h`, `linux/mfd/intel_soc_pmic.h`.
- Detected declarations: `struct cht_wc_i2c_adap`, `function cht_wc_i2c_adap_thread_handler`, `function cht_wc_i2c_adap_func`, `function cht_wc_i2c_adap_smbus_xfer`, `function cht_wc_i2c_adap_lock_bus`, `function cht_wc_i2c_adap_trylock_bus`, `function cht_wc_i2c_adap_unlock_bus`, `function cht_wc_i2c_irq_lock`, `function cht_wc_i2c_irq_sync_unlock`, `function cht_wc_i2c_irq_enable`.
- Atlas domain: Driver Families / drivers/i2c.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- 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.