drivers/greybus/operation.c
Source file repositories/reference/linux-study-clean/drivers/greybus/operation.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/greybus/operation.c- Extension
.c- Size
- 35835 bytes
- Lines
- 1266
- Domain
- Driver Families
- Bucket
- drivers/greybus
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- 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/kernel.hlinux/slab.hlinux/module.hlinux/sched.hlinux/wait.hlinux/workqueue.hlinux/greybus.hgreybus_trace.h
Detected Declarations
function gb_operation_get_activefunction gb_operation_put_activefunction gb_operation_is_activefunction afunction gb_operation_resultfunction gb_operation_find_outgoingfunction gb_message_sendfunction gb_message_cancelfunction gb_operation_request_handlefunction gb_operation_workfunction gb_operation_timeoutfunction gb_operation_message_initfunction gb_operation_message_allocfunction gb_operation_message_freefunction valuefunction valuefunction gb_operation_response_allocfunction gb_operation_create_commonfunction gb_operation_create_flagsfunction gb_operation_create_corefunction gb_operation_get_payload_size_maxfunction gb_operation_create_incomingfunction gb_operation_getfunction _gb_operation_destroyfunction gb_operation_putfunction gb_operation_sync_callbackfunction gb_operation_request_sendfunction gb_operation_request_send_sync_timeoutfunction gb_operation_response_sendfunction greybus_message_sentfunction gb_connection_recv_requestfunction gb_connection_recv_responsefunction reusedfunction gb_operation_cancelfunction gb_operation_cancel_incomingfunction gb_operation_sync_timeoutfunction gb_operation_unidirectional_timeoutfunction gb_operation_initfunction gb_operation_exitexport gb_operation_resultexport gb_operation_response_allocexport gb_operation_create_flagsexport gb_operation_get_payload_size_maxexport gb_operation_getexport gb_operation_putexport gb_operation_request_sendexport gb_operation_request_send_sync_timeoutexport greybus_message_sent
Annotated Snippet
if (!ret) {
/* Cancel request message if scheduled by timeout. */
if (gb_operation_result(operation) == -ETIMEDOUT)
gb_message_cancel(operation->request);
}
operation->callback(operation);
}
gb_operation_put_active(operation);
gb_operation_put(operation);
}
static void gb_operation_timeout(struct timer_list *t)
{
struct gb_operation *operation = timer_container_of(operation, t,
timer);
if (gb_operation_result_set(operation, -ETIMEDOUT)) {
/*
* A stuck request message will be cancelled from the
* workqueue.
*/
queue_work(gb_operation_completion_wq, &operation->work);
}
}
static void gb_operation_message_init(struct gb_host_device *hd,
struct gb_message *message,
u16 operation_id,
size_t payload_size, u8 type)
{
struct gb_operation_msg_hdr *header;
header = message->buffer;
message->header = header;
message->payload = payload_size ? header + 1 : NULL;
message->payload_size = payload_size;
/*
* The type supplied for incoming message buffers will be
* GB_REQUEST_TYPE_INVALID. Such buffers will be overwritten by
* arriving data so there's no need to initialize the message header.
*/
if (type != GB_REQUEST_TYPE_INVALID) {
u16 message_size = (u16)(sizeof(*header) + payload_size);
/*
* For a request, the operation id gets filled in
* when the message is sent. For a response, it
* will be copied from the request by the caller.
*
* The result field in a request message must be
* zero. It will be set just prior to sending for
* a response.
*/
header->size = cpu_to_le16(message_size);
header->operation_id = 0;
header->type = type;
header->result = 0;
}
}
/*
* Allocate a message to be used for an operation request or response.
* Both types of message contain a common header. The request message
* for an outgoing operation is outbound, as is the response message
* for an incoming operation. The message header for an outbound
* message is partially initialized here.
*
* The headers for inbound messages don't need to be initialized;
* they'll be filled in by arriving data.
*
* Our message buffers have the following layout:
* message header \_ these combined are
* message payload / the message size
*/
static struct gb_message *
gb_operation_message_alloc(struct gb_host_device *hd, u8 type,
size_t payload_size, gfp_t gfp_flags)
{
struct gb_message *message;
struct gb_operation_msg_hdr *header;
size_t message_size = payload_size + sizeof(*header);
if (message_size > hd->buffer_size_max) {
dev_warn(&hd->dev, "requested message size too big (%zu > %zu)\n",
message_size, hd->buffer_size_max);
return NULL;
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/slab.h`, `linux/module.h`, `linux/sched.h`, `linux/wait.h`, `linux/workqueue.h`, `linux/greybus.h`, `greybus_trace.h`.
- Detected declarations: `function gb_operation_get_active`, `function gb_operation_put_active`, `function gb_operation_is_active`, `function a`, `function gb_operation_result`, `function gb_operation_find_outgoing`, `function gb_message_send`, `function gb_message_cancel`, `function gb_operation_request_handle`, `function gb_operation_work`.
- Atlas domain: Driver Families / drivers/greybus.
- Implementation status: integration implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.