drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
Source file repositories/reference/linux-study-clean/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h- Extension
.h- Size
- 8193 bytes
- Lines
- 288
- Domain
- Driver Families
- Bucket
- drivers/hid
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/types.hlinux/spinlock.hlinux/intel-ish-client-if.hbus.hhbm.h
Detected Declarations
struct ishtp_clstruct ishtp_fw_clientstruct wr_msg_ctl_infostruct ishtp_hw_opsstruct ishtp_driver_datastruct ish_versionstruct ishtp_deviceenum ishtp_dev_statefunction ishtp_secs_to_jiffiesfunction ish_ipc_reset
Annotated Snippet
struct ishtp_fw_client {
struct ishtp_client_properties props;
uint8_t client_id;
};
/*
* Control info for IPC messages ISHTP/IPC sending FIFO -
* list with inline data buffer
* This structure will be filled with parameters submitted
* by the caller glue layer
* 'buf' may be pointing to the external buffer or to 'inline_data'
* 'offset' will be initialized to 0 by submitting
*
* 'ipc_send_compl' is intended for use by clients that send fragmented
* messages. When a fragment is sent down to IPC msg regs,
* it will be called.
* If it has more fragments to send, it will do it. With last fragment
* it will send appropriate ISHTP "message-complete" flag.
* It will remove the outstanding message
* (mark outstanding buffer as available).
* If counting flow control is in work and there are more flow control
* credits, it can put the next client message queued in cl.
* structure for IPC processing.
*
*/
struct wr_msg_ctl_info {
/* Will be called with 'ipc_send_compl_prm' as parameter */
void (*ipc_send_compl)(void *);
void *ipc_send_compl_prm;
size_t length;
struct list_head link;
unsigned char inline_data[IPC_FULL_MSG_SIZE];
};
/*
* The ISHTP layer talks to hardware IPC message using the following
* callbacks
*/
struct ishtp_hw_ops {
int (*hw_reset)(struct ishtp_device *dev);
int (*ipc_reset)(struct ishtp_device *dev);
uint32_t (*ipc_get_header)(struct ishtp_device *dev, int length,
int busy);
int (*write)(struct ishtp_device *dev,
void (*ipc_send_compl)(void *), void *ipc_send_compl_prm,
unsigned char *msg, int length);
uint32_t (*ishtp_read_hdr)(const struct ishtp_device *dev);
int (*ishtp_read)(struct ishtp_device *dev, unsigned char *buffer,
unsigned long buffer_length);
uint32_t (*get_fw_status)(struct ishtp_device *dev);
void (*sync_fw_clock)(struct ishtp_device *dev);
bool (*dma_no_cache_snooping)(struct ishtp_device *dev);
};
/**
* struct ishtp_driver_data - Driver-specific data for ISHTP devices
*
* This structure holds driver-specific data that can be associated with each
* ISHTP device instance. It allows for the storage of data that is unique to
* a particular driver or hardware variant.
*
* @fw_generation: The generation name associated with a specific hardware
* variant of the Intel Integrated Sensor Hub (ISH). This allows
* the driver to load the correct firmware based on the device's
* hardware variant. For example, "lnlm" for the Lunar Lake-M
* platform. The generation name must not exceed 8 characters
* in length.
*/
struct ishtp_driver_data {
char *fw_generation;
};
struct ish_version {
u16 major;
u16 minor;
u16 hotfix;
u16 build;
};
/**
* struct ishtp_device - ISHTP private device struct
*/
struct ishtp_device {
struct device *devc; /* pointer to lowest device */
struct pci_dev *pdev; /* PCI device to get device ids */
struct ishtp_driver_data *driver_data; /* pointer to driver-specific data */
/* waitq for waiting for suspend response */
wait_queue_head_t suspend_wait;
Annotation
- Immediate include surface: `linux/types.h`, `linux/spinlock.h`, `linux/intel-ish-client-if.h`, `bus.h`, `hbm.h`.
- Detected declarations: `struct ishtp_cl`, `struct ishtp_fw_client`, `struct wr_msg_ctl_info`, `struct ishtp_hw_ops`, `struct ishtp_driver_data`, `struct ish_version`, `struct ishtp_device`, `enum ishtp_dev_state`, `function ishtp_secs_to_jiffies`, `function ish_ipc_reset`.
- Atlas domain: Driver Families / drivers/hid.
- Implementation status: source implementation candidate.
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.