drivers/ptp/ptp_vmclock.c
Source file repositories/reference/linux-study-clean/drivers/ptp/ptp_vmclock.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/ptp/ptp_vmclock.c- Extension
.c- Size
- 19951 bytes
- Lines
- 792
- Domain
- Driver Families
- Bucket
- drivers/ptp
- Inferred role
- Driver Families: operation-table or driver-model contract
- Status
- pattern 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 an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- 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/poll.hlinux/types.hlinux/wait.hlinux/acpi.hlinux/device.hlinux/err.hlinux/file.hlinux/fs.hlinux/init.hlinux/io.hlinux/interrupt.hlinux/kernel.hlinux/miscdevice.hlinux/mm.hlinux/module.hlinux/of.hlinux/platform_device.hlinux/slab.huapi/linux/vmclock-abi.hlinux/ptp_clock_kernel.hasm/pvclock.hasm/kvmclock.h
Detected Declarations
struct vmclock_statestruct vmclock_file_statefunction tai_adjustfunction vmclock_get_crosststampfunction gettimex64function get_device_system_crosststampfunction ptp_vmclock_get_time_fnfunction ptp_vmclock_getcrosststampfunction get_device_system_crosststampfunction ptp_vmclock_adjfinefunction ptp_vmclock_adjtimefunction ptp_vmclock_settimefunction ptp_vmclock_gettimexfunction ptp_vmclock_enablefunction vmclock_miscdev_mmapfunction vmclock_miscdev_readfunction vmclock_miscdev_pollfunction vmclock_miscdev_openfunction vmclock_miscdev_releasefunction vmclock_acpi_resourcesfunction vmclock_acpi_notification_handlerfunction vmclock_setup_acpi_notificationfunction vmclock_probe_acpifunction vmclock_of_irq_handlerfunction vmclock_probe_dtfunction vmclock_setup_of_notificationfunction vmclock_setup_notificationfunction vmclock_removefunction vmclock_put_idxfunction vmclock_probe
Annotated Snippet
static const struct file_operations vmclock_miscdev_fops = {
.owner = THIS_MODULE,
.open = vmclock_miscdev_open,
.release = vmclock_miscdev_release,
.mmap = vmclock_miscdev_mmap,
.read = vmclock_miscdev_read,
.poll = vmclock_miscdev_poll,
};
/* module operations */
#if IS_ENABLED(CONFIG_ACPI)
static acpi_status vmclock_acpi_resources(struct acpi_resource *ares, void *data)
{
struct vmclock_state *st = data;
struct resource_win win;
struct resource *res = &win.res;
if (ares->type == ACPI_RESOURCE_TYPE_END_TAG)
return AE_OK;
/* There can be only one */
if (resource_type(&st->res) == IORESOURCE_MEM)
return AE_ERROR;
if (acpi_dev_resource_memory(ares, res) ||
acpi_dev_resource_address_space(ares, &win)) {
if (resource_type(res) != IORESOURCE_MEM ||
resource_size(res) < sizeof(st->clk))
return AE_ERROR;
st->res = *res;
return AE_OK;
}
return AE_ERROR;
}
static void
vmclock_acpi_notification_handler(acpi_handle __always_unused handle,
u32 __always_unused event, void *dev)
{
struct device *device = dev;
struct vmclock_state *st = device->driver_data;
wake_up_interruptible(&st->disrupt_wait);
}
static int vmclock_setup_acpi_notification(struct device *dev)
{
struct acpi_device *adev = ACPI_COMPANION(dev);
acpi_status status;
/*
* This should never happen as this function is only called when
* has_acpi_companion(dev) is true, but the logic is sufficiently
* complex that Coverity can't see the tautology.
*/
if (!adev)
return -ENODEV;
status = acpi_install_notify_handler(adev->handle, ACPI_DEVICE_NOTIFY,
vmclock_acpi_notification_handler,
dev);
if (ACPI_FAILURE(status)) {
dev_err(dev, "failed to install notification handler");
return -ENODEV;
}
return 0;
}
static int vmclock_probe_acpi(struct device *dev, struct vmclock_state *st)
{
struct acpi_device *adev = ACPI_COMPANION(dev);
acpi_status status;
/*
* This should never happen as this function is only called when
* has_acpi_companion(dev) is true, but the logic is sufficiently
* complex that Coverity can't see the tautology.
*/
if (!adev)
return -ENODEV;
status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
vmclock_acpi_resources, st);
if (ACPI_FAILURE(status) || resource_type(&st->res) != IORESOURCE_MEM) {
dev_err(dev, "failed to get resources\n");
Annotation
- Immediate include surface: `linux/poll.h`, `linux/types.h`, `linux/wait.h`, `linux/acpi.h`, `linux/device.h`, `linux/err.h`, `linux/file.h`, `linux/fs.h`.
- Detected declarations: `struct vmclock_state`, `struct vmclock_file_state`, `function tai_adjust`, `function vmclock_get_crosststamp`, `function gettimex64`, `function get_device_system_crosststamp`, `function ptp_vmclock_get_time_fn`, `function ptp_vmclock_getcrosststamp`, `function get_device_system_crosststamp`, `function ptp_vmclock_adjfine`.
- Atlas domain: Driver Families / drivers/ptp.
- Implementation status: pattern implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
- 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.