struct_device - The basic device structure
2. SYNOPSIS ▲
*dma_mask; u64 coherent_dma_mask;
structacpi_dev_node acpi_node; dev_t devt; u32 id; spinlock_t devres_lock;
3. MEMBERS ▲
The deviceAqs « parent » device, the device to which it is attached. In most cases, a parent device is some sort of bus or host controller. If parent is NULL, the device, is a top-level device, which is not usually what you want.
Holds the private data of the driver core portions of the device. See the comment of the struct device_private for detail.
A top-level, abstract class from which other classes are derived.
Initial name of the device.
The type of device. This identifies the device type and carries type-specific information.
Mutex to synchronize calls to its driver.
Type of bus device is on.
Which driver has allocated this
Platform data specific to the device.
For device power management. See Documentation/power/devices.txt for details.
Provide callbacks that are executed during system suspend, hibernation, system resume and during runtime PM transitions along with subsystem-level and driver-level callbacks.
For device pin management. See Documentation/pinctrl.txt for details.
NUMA node this device is close to.
Dma mask (if dmaAqble device).
Like dma_mask, but for alloc_coherent mapping as not all hardware supports 64-bit addresses for consistent allocations such descriptors.
A low level driver may set these to teach IOMMU code about segment limitations.
Dma pools (if dmaAqble device).
Internal for coherent mem override.
For arch-specific additions.
Associated device tree node.
Associated ACPI device node.
For creating the sysfs « dev ».
Spinlock to protect the resource of the device.
The resources list of the device.
The node used to add the device to the class list.
The class of the device.
Optional attribute groups.
Callback to free the device after all references have gone away. This should be set by the allocator of the device (i.e. the bus driver that discovered the device).
4. EXAMPLE ▲
For devices on custom boards, as typical of embedded and SOC based hardware, Linux often uses platform_data to point to board
-specific structures describing devices and how they are wired. That can include what ports are available, chip variants, which GPIO pins act in what additional roles, and so on. This shrinks the « Board Support Packages »
(BSPs) and minimizes board
-specific #ifdefs in drivers.
5. DESCRIPTION ▲
At the lowest level, every device in a Linux system is represented by an instance of struct device. The device structure contains the information that the device model core needs to model the system. Most subsystems, however, track additional information about the devices they host. As a result, it is rare for devices to be represented by bare device structures; instead, that structure, like kobject structures, is usually embedded within a higher-level representation of the device.
6. COPYRIGHT ▲