The bus type of the device
Definition
struct bus_type {
const char * name;
const char * dev_name;
struct device * dev_root;
struct device_attribute * dev_attrs;
const struct attribute_group ** bus_groups;
const struct attribute_group ** dev_groups;
const struct attribute_group ** drv_groups;
int (* match) (struct device *dev, struct device_driver *drv);
int (* uevent) (struct device *dev, struct kobj_uevent_env *env);
int (* probe) (struct device *dev);
int (* remove) (struct device *dev);
void (* shutdown) (struct device *dev);
int (* online) (struct device *dev);
int (* offline) (struct device *dev);
int (* suspend) (struct device *dev, pm_message_t state);
int (* resume) (struct device *dev);
int (* num_vf) (struct device *dev);
const struct dev_pm_ops * pm;
const struct iommu_ops * iommu_ops;
struct subsys_private * p;
struct lock_class_key lock_key;
};
Members
Description
A bus is a channel between the processor and one or more devices. For the purposes of the device model, all devices are connected via a bus, even if it is an internal, virtual, “platform” bus. Buses can plug into each other. A USB controller is usually a PCI device, for example. The device model represents the actual connections between buses and the devices they control. A bus is represented by the bus_type structure. It contains the name, the default attributes, the bus’ methods, PM operations, and the driver core’s private data.
device driver probe type to try Device drivers may opt in for special handling of their respective probe routines. This tells the core what to expect and prefer.
Constants
Description
Note that the end goal is to switch the kernel to use asynchronous probing by default, so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary measure that allows us to speed up boot process while we are validating the rest of the drivers.
The basic device driver structure
Definition
struct device_driver {
const char * name;
struct bus_type * bus;
struct module * owner;
const char * mod_name;
bool suppress_bind_attrs;
enum probe_type probe_type;
const struct of_device_id * of_match_table;
const struct acpi_device_id * acpi_match_table;
int (* probe) (struct device *dev);
int (* remove) (struct device *dev);
void (* shutdown) (struct device *dev);
int (* suspend) (struct device *dev, pm_message_t state);
int (* resume) (struct device *dev);
const struct attribute_group ** groups;
const struct dev_pm_ops * pm;
struct driver_private * p;
};
Members
Description
The device driver-model tracks all of the drivers known to the system. The main reason for this tracking is to enable the driver core to match up drivers with new devices. Once drivers are known objects within the system, however, a number of other things become possible. Device drivers can export information and configuration variables that are independent of any specific device.
interfaces to device functions
Definition
struct subsys_interface {
const char * name;
struct bus_type * subsys;
struct list_head node;
int (* add_dev) (struct device *dev, struct subsys_interface *sif);
void (* remove_dev) (struct device *dev, struct subsys_interface *sif);
};
Members
Description
Simple interfaces attached to a subsystem. Multiple interfaces can attach to a subsystem and its devices. Unlike drivers, they do not exclusively claim or control devices. Interfaces usually represent a specific functionality of a subsystem/class of devices.
device classes
Definition
struct class {
const char * name;
struct module * owner;
struct class_attribute * class_attrs;
const struct attribute_group ** class_groups;
const struct attribute_group ** dev_groups;
struct kobject * dev_kobj;
int (* dev_uevent) (struct device *dev, struct kobj_uevent_env *env);
char *(* devnode) (struct device *dev, umode_t *mode);
void (* class_release) (struct class *class);
void (* dev_release) (struct device *dev);
int (* suspend) (struct device *dev, pm_message_t state);
int (* resume) (struct device *dev);
const struct kobj_ns_type_operations * ns_type;
const void *(* namespace) (struct device *dev);
const struct dev_pm_ops * pm;
struct subsys_private * p;
};
Members
Description
A class is a higher-level view of a device that abstracts out low-level implementation details. Drivers may see a SCSI disk or an ATA disk, but, at the class level, they are all simply disks. Classes allow user space to work with devices based on what they do, rather than how they are connected or how they work.
Resource-managed alloc_percpu
Parameters
Description
Managed alloc_percpu. Per-cpu memory allocated with this function is automatically freed on driver detach.
Return
Pointer to allocated memory on success, NULL on failure.
Device link states.
Constants
Device link representation.
Definition
struct device_link {
struct device * supplier;
struct list_head s_node;
struct device * consumer;
struct list_head c_node;
enum device_link_state status;
u32 flags;
bool rpm_active;
#ifdef CONFIG_SRCU
struct rcu_head rcu_head;
#endif
};
Members
Device driver presence tracking information.
Constants
Device data related to device links.
Definition
struct dev_links_info {
struct list_head suppliers;
struct list_head consumers;
enum dl_dev_state status;
};
Members
The basic device structure
Definition
struct device {
struct device * parent;
struct device_private * p;
struct kobject kobj;
const char * init_name;
const struct device_type * type;
struct mutex mutex;
struct bus_type * bus;
struct device_driver * driver;
void * platform_data;
void * driver_data;
struct dev_links_info links;
struct dev_pm_info power;
struct dev_pm_domain * pm_domain;
#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
struct irq_domain * msi_domain;
#endif
#ifdef CONFIG_PINCTRL
struct dev_pin_info * pins;
#endif
#ifdef CONFIG_GENERIC_MSI_IRQ
struct list_head msi_list;
#endif
#ifdef CONFIG_NUMA
int numa_node;
#endif
u64 * dma_mask;
u64 coherent_dma_mask;
unsigned long dma_pfn_offset;
struct device_dma_parameters * dma_parms;
struct list_head dma_pools;
struct dma_coherent_mem * dma_mem;
#ifdef CONFIG_DMA_CMA
struct cma * cma_area;
#endif
struct dev_archdata archdata;
struct device_node * of_node;
struct fwnode_handle * fwnode;
dev_t devt;
u32 id;
spinlock_t devres_lock;
struct list_head devres_head;
struct klist_node knode_class;
struct class * class;
const struct attribute_group ** groups;
void (* release) (struct device *dev);
struct iommu_group * iommu_group;
struct iommu_fwspec * iommu_fwspec;
bool offline_disabled:1;
bool offline:1;
};
Members
Example
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.
Helper macro for drivers that don’t do anything special in module init/exit. This eliminates a lot of boilerplate. Each module may only use this macro once, and calling it replaces module_init() and module_exit().
Parameters
Description
Use this macro to construct bus specific macros for registering drivers, and do not use it on its own.
Helper macro for drivers that don’t do anything special in init and have no exit. This eliminates some boilerplate. Each driver may only use this macro once, and calling it replaces device_initcall (or in some cases, the legacy __initcall). This is meant to be a direct parallel of module_driver() above but without the __exit stuff that is not used for builtin cases.
Parameters
Description
Use this macro to construct bus specific macros for registering drivers, and do not use it on its own.
initialize driver model.
Parameters
Description
Call the driver model init functions to initialize their subsystems. Called early from init/main.c.
Iterator for devices bound to a driver.
Parameters
Description
Iterate over the drv‘s list of devices calling fn for each one.
device iterator for locating a particular device.
Parameters
Description
This is similar to the driver_for_each_device() function above, but it returns a reference to a device that is ‘found’ for later use, as determined by the match callback.
The callback should return 0 if the device doesn’t match and non-zero if it does. If the callback returns non-zero, this function will return to the caller and not iterate over any more devices.
create sysfs file for driver.
Parameters
remove sysfs file for driver.
Parameters
register driver with bus
Parameters
Description
We pass off most of the work to the bus_add_driver() call, since most of the things we have to do deal with the bus structures.
remove driver from system.
Parameters
Description
Again, we pass off most of the work to the bus-level call.
locate driver on a bus by its name.
Parameters
Description
Call kset_find_obj() to iterate over list of drivers on a bus to find driver by name. Return driver if found.
This routine provides no locking to prevent the driver it returns from being unregistered or unloaded while the caller is using it. The caller is responsible for preventing this.
Create a link between two devices.
Parameters
Description
The caller is responsible for the proper synchronization of the link creation with runtime PM. First, setting the DL_FLAG_PM_RUNTIME flag will cause the runtime PM framework to take the link into account. Second, if the DL_FLAG_RPM_ACTIVE flag is set in addition to it, the supplier devices will be forced into the active metastate and reference-counted upon the creation of the link. If DL_FLAG_PM_RUNTIME is not set, DL_FLAG_RPM_ACTIVE will be ignored.
If the DL_FLAG_AUTOREMOVE is set, the link will be removed automatically when the consumer device driver unbinds from it. The combination of both DL_FLAG_AUTOREMOVE and DL_FLAG_STATELESS set is invalid and will cause NULL to be returned.
A side effect of the link creation is re-ordering of dpm_list and the devices_kset list by moving the consumer device and all devices depending on it to the ends of these lists (that does not happen to devices that have not been registered when this function is called).
The supplier device is required to be registered when this function is called and NULL will be returned if that is not the case. The consumer device need not be registered, however.
Delete a link between two devices.
Parameters
Description
The caller must ensure proper synchronization of this function with runtime PM.
Return a device’s driver name, if at all possible
Parameters
Description
Will return the device’s driver’s name if it is bound to a device. If the device is not bound to a driver, it will return the name of the bus it is attached to. If it is not attached to a bus either, an empty string will be returned.
create sysfs attribute file for device.
Parameters
remove sysfs attribute file.
Parameters
remove sysfs attribute file from its own method.
Parameters
Description
See kernfs_remove_self() for details.
create sysfs binary attribute file for device.
Parameters
remove sysfs binary attribute file
Parameters
Parameters
Description
This prepares the device for use by other layers by initializing its fields. It is the first half of device_register(), if called by that function, though it can also be called separately, so one may use dev‘s fields. In particular, get_device()/put_device() may be used for reference counting of dev after calling this function.
All fields in dev must be initialized by the caller to 0, except for those explicitly set to some other value. The simplest approach is to use kzalloc() to allocate the structure containing dev.
NOTE
Use put_device() to give up your reference instead of freeing dev directly once you have called this function.
Parameters
Parameters
Description
This is part 2 of device_register(), though may be called separately _iff_ device_initialize() has been called separately.
This adds dev to the kobject hierarchy via kobject_add(), adds it to the global and sibling lists for the device, then adds it to the other relevant subsystems of the driver model.
Do not call this routine or device_register() more than once for any device structure. The driver model core is not designed to work with devices that get unregistered and then spring back to life. (Among other things, it’s very hard to guarantee that all references to the previous incarnation of dev have been dropped.) Allocate and register a fresh new struct device instead.
NOTE
_Never_ directly free dev after calling this function, even if it returned an error! Always use put_device() to give up your reference instead.
Parameters
Description
This happens in two clean steps - initialize the device and add it to the system. The two steps can be called separately, but this is the easiest and most common. I.e. you should only call the two helpers separately if have a clearly defined need to use and refcount the device before it is added to the hierarchy.
For more information, see the kerneldoc for device_initialize() and device_add().
NOTE
_Never_ directly free dev after calling this function, even if it returned an error! Always use put_device() to give up the reference initialized in this function instead.
Parameters
Description
This simply forwards the call to kobject_get(), though we do take care to provide for the case that we get a NULL pointer passed in.
Parameters
Parameters
Description
This is the first part of the device unregistration sequence. This removes the device from the lists we control from here, has it removed from the other driver model subsystems it was added to in device_add(), and removes it from the kobject hierarchy.
NOTE
this should be called manually _iff_ device_add() was also called manually.
Parameters
Description
We do this in two parts, like we do device_register(). First, we remove it from all the subsystems with device_del(), then we decrement the reference count via put_device(). If that is the final reference count, the device will be cleaned up via device_release() above. Otherwise, the structure will stick around until the final reference to the device is dropped.
device child iterator.
Parameters
Description
Iterate over parent‘s child devices, and call fn for each, passing it data.
We check the return of fn each time. If it returns anything other than 0, we break out and return that value.
device child iterator in reversed order.
Parameters
Description
Iterate over parent‘s child devices, and call fn for each, passing it data.
We check the return of fn each time. If it returns anything other than 0, we break out and return that value.
device iterator for locating a particular device.
Parameters
Description
This is similar to the device_for_each_child() function above, but it returns a reference to a device that is ‘found’ for later use, as determined by the match callback.
The callback should return 0 if the device doesn’t match and non-zero if it does. If the callback returns non-zero and a reference to the current device can be obtained, this function will return to the caller and not iterate over any more devices.
NOTE
you will need to drop the reference with put_device() after use.
allocate and register a root device
Parameters
Description
This function allocates a root device and registers it using device_register(). In order to free the returned device, use root_device_unregister().
Root devices are dummy devices which allow other devices to be grouped under /sys/devices. Use this function to allocate a root device and then use it as the parent of any device which should appear under /sys/devices/{name}
The /sys/devices/{name} directory will also contain a ‘module’ symlink which points to the owner directory in sysfs.
Returns struct device pointer on success, or ERR_PTR() on error.
Note
You probably want to use root_device_register().
Parameters
Description
This function unregisters and cleans up a device that was created by root_device_register().
creates a device and registers it with sysfs
Parameters
Description
This function can be used by char device classes. A struct device will be created in sysfs, registered to the specified class.
A “dev” file will be created, showing the dev_t for the device, if the dev_t is not 0,0. If a pointer to a parent struct device is passed in, the newly created struct device will be a child of that device in sysfs. The pointer to the struct device will be returned from the call. Any further sysfs files that might be required can be created using this pointer.
Returns struct device pointer on success, or ERR_PTR() on error.
Note
the struct class passed to this function must have previously been created with a call to class_create().
creates a device and registers it with sysfs
Parameters
Description
This function can be used by char device classes. A struct device will be created in sysfs, registered to the specified class.
A “dev” file will be created, showing the dev_t for the device, if the dev_t is not 0,0. If a pointer to a parent struct device is passed in, the newly created struct device will be a child of that device in sysfs. The pointer to the struct device will be returned from the call. Any further sysfs files that might be required can be created using this pointer.
Returns struct device pointer on success, or ERR_PTR() on error.
Note
the struct class passed to this function must have previously been created with a call to class_create().
creates a device and registers it with sysfs
Parameters
Description
This function can be used by char device classes. A struct device will be created in sysfs, registered to the specified class. Additional attributes specified in the groups parameter will also be created automatically.
A “dev” file will be created, showing the dev_t for the device, if the dev_t is not 0,0. If a pointer to a parent struct device is passed in, the newly created struct device will be a child of that device in sysfs. The pointer to the struct device will be returned from the call. Any further sysfs files that might be required can be created using this pointer.
Returns struct device pointer on success, or ERR_PTR() on error.
Note
the struct class passed to this function must have previously been created with a call to class_create().
removes a device that was created with device_create()
Parameters
Description
This call unregisters and cleans up a device that was created with a call to device_create().
Parameters
Description
It is the responsibility of the caller to provide mutual exclusion between two different calls of device_rename on the same device to ensure that new_name is valid and won’t conflict with other devices.
Note
Don’t call this function. Currently, the networking layer calls this function, but that will change. The following text from Kay Sievers offers some insight:
Renaming devices is racy at many levels, symlinks and other stuff are not replaced atomically, and you get a “move” uevent, but it’s not easy to connect the event to the old and new device. Device nodes are not renamed at all, there isn’t even support for that in the kernel now.
In the meantime, during renaming, your target name might be taken by another driver, creating conflicts. Or the old name is taken directly after you renamed it – then you get events for the same DEVPATH, before you even see the “move” event. It’s just a mess, and nothing new should ever rely on kernel device renaming. Besides that, it’s not even implemented now for other things than (driver-core wise very simple) network devices.
We are currently about to change network renaming in udev to completely disallow renaming of devices in the same namespace as the kernel uses, because we can’t solve the problems properly, that arise with swapping names of multiple interfaces without races. Means, renaming of eth[0-9]* will only be allowed to some other name than eth[0-9]*, for the aforementioned reasons.
Make up a “real” name in the driver before you register anything, or add some other attributes for userspace to find the device, or use udev to add symlinks – but never rename kernel devices later, it’s a complete mess. We don’t even want to get into that and try to implement the missing pieces in the core. We really have other pieces to fix in the driver core mess. :)
moves a device to a new parent
Parameters
Change the primary firmware node of a given device.
Parameters
Description
Set the device’s firmware node pointer to fwnode, but if a secondary firmware node of the device is present, preserve it.
Register a set of system core operations.
Parameters
Unregister a set of system core operations.
Parameters
Execute all the registered system core suspend callbacks.
Parameters
Description
This function is executed with one CPU on-line and disabled interrupts.
Execute all the registered system core resume callbacks.
Parameters
Description
This function is executed with one CPU on-line and disabled interrupts.
create a struct class structure
Parameters
Description
This is used to create a struct class pointer that can then be used in calls to device_create().
Returns struct class pointer on success, or ERR_PTR() on error.
Note, the pointer created here is to be destroyed when finished by making a call to class_destroy().
Parameters
Description
Note, the pointer to be destroyed must have been created with a call to class_create().
initialize class device iterator
Parameters
Description
Initialize class iterator iter such that it iterates over devices of class. If start is set, the list iteration will start there, otherwise if it is NULL, the iteration starts at the beginning of the list.
Parameters
Description
Proceed iter to the next device and return it. Returns NULL if iteration is complete.
The returned device is referenced and won’t be released till iterator is proceed to the next device or exited. The caller is free to do whatever it wants to do with the device including calling back into class code.
finish iteration
Parameters
Description
Finish an iteration. Always call this function after iteration is complete whether the iteration ran till the end or not.
device iterator
Parameters
Description
Iterate over class‘s list of devices, and call fn for each, passing it data. If start is set, the list iteration will start there, otherwise if it is NULL, the iteration starts at the beginning of the list.
We check the return of fn each time. If it returns anything other than 0, we break out and return that value.
fn is allowed to do anything including calling back into class code. There’s no locking restriction.
device iterator for locating a particular device
Parameters
Description
This is similar to the class_for_each_dev() function above, but it returns a reference to a device that is ‘found’ for later use, as determined by the match callback.
The callback should return 0 if the device doesn’t match and non-zero if it does. If the callback returns non-zero, this function will return to the caller and not iterate over any more devices.
Note, you will need to drop the reference with put_device() after use.
match is allowed to do anything including calling back into class code. There’s no locking restriction.
register a compatibility class
Parameters
Description
Compatibility class are meant as a temporary user-space compatibility workaround when converting a family of class devices to a bus devices.
unregister a compatibility class
Parameters
create a compatibility class device link to a bus device
Parameters
remove a compatibility class device link to a bus device
Parameters
unregister a node device
Parameters
Description
Unregisters a node device node. All the devices on the node must be unregistered before calling this function.
send firmware request and wait for it
Parameters
Description
firmware_p will be used to return a firmware image by the name of name for device device.
Should be called from user context where sleeping is allowed.
name will be used as $FIRMWARE in the uevent environment and should be distinctive enough not to be confused with any other firmware image for this or any other device.
Caller must hold the reference count of device.
The function can be called safely inside device’s suspend and resume callback.
load firmware directly without usermode helper
Parameters
Description
This function works pretty much like request_firmware(), but this doesn’t fall back to usermode helper even if the firmware couldn’t be loaded directly from fs. Hence it’s useful for loading optional firmwares, which aren’t always present, without extra long timeouts of udev.
load firmware into a previously allocated buffer
Parameters
Description
This function works pretty much like request_firmware(), but it doesn’t allocate a buffer to hold the firmware data. Instead, the firmware is loaded directly into the buffer pointed to by buf and the firmware_p data member is pointed at buf.
This function doesn’t cache firmware either.
release the resource associated with a firmware image
Parameters
asynchronous version of request_firmware
Parameters
Description
Caller must hold the reference count of device.
- Asynchronous variant of request_firmware() for user contexts:
- sleep for as small periods as possible since it may increase kernel boot time of built-in device drivers requesting firmware in their ->:c:func:probe() methods, if gfp is GFP_KERNEL.
- can’t sleep at all if gfp is GFP_ATOMIC.
register an initial transport class
Parameters
Description
The transport class contains an embedded class which is used to identify it. The caller should initialise this structure with zeros and then generic class must have been initialised with the actual transport class unique name. There’s a macro DECLARE_TRANSPORT_CLASS() to do this (declared classes still must be registered).
Returns 0 on success or error on failure.
unregister a previously registered class
Parameters
Description
Must be called prior to deallocating the memory for the transport class.
register an anonymous class
Parameters
Description
The anonymous transport class contains both a transport class and a container. The idea of an anonymous class is that it never actually has any device attributes associated with it (and thus saves on container storage). So it can only be used for triggering events. Use prezero and then use DECLARE_ANON_TRANSPORT_CLASS() to initialise the anon transport class storage.
unregister an anon class
Parameters
Description
Must be called prior to deallocating the memory for the anon transport class.
declare a new dev for transport class association but don’t make it visible yet.
Parameters
Description
Usually, dev represents some component in the HBA system (either the HBA itself or a device remote across the HBA bus). This routine is simply a trigger point to see if any set of transport classes wishes to associate with the added device. This allocates storage for the class device and initialises it, but does not yet add it to the system or add attributes to it (you do this with transport_add_device). If you have no need for a separate setup and add operations, use transport_register_device (see transport_class.h).
Parameters
Description
Usually, dev represents some component in the HBA system (either the HBA itself or a device remote across the HBA bus). This routine is simply a trigger point used to add the device to the system and register attributes for it.
Parameters
Description
The idea of configure is simply to provide a point within the setup process to allow the transport class to extract information from a device after it has been setup. This is used in SCSI because we have to have a setup device to begin using the HBA, but after we send the initial inquiry, we use configure to extract the device parameters. The device need not have been added to be configured.
Parameters
Description
This call removes the visibility of the device (to the user from sysfs), but does not destroy it. To eliminate a device entirely you must also call transport_destroy_device. If you don’t need to do remove and destroy as separate operations, use transport_unregister_device() (see transport_class.h) which will perform both calls for you.
Parameters
Description
This call triggers the elimination of storage associated with the transport classdev. Note: all it really does is relinquish a reference to the classdev. The memory will not be freed until the last reference goes to zero. Note also that the classdev retains a reference count on dev, so dev too will remain for as long as the transport class device remains around.
Parameters
Description
Allow manual attachment of a driver to a device. Caller must have already set dev->driver.
Note that this does not modify the bus reference count nor take the bus’s rwsem. Please verify those are accounted for before calling this. (It is ok to call with no other effort from a driver’s probe() method.)
This function must be called with the device lock held.
Parameters
Description
Wait for device probing to be completed.
Parameters
Description
Walk the list of drivers that the bus has and call driver_probe_device() for each pair. If a compatible pair is found, break out and return.
Returns 1 if the device was bound to a driver; 0 if no matching driver was found; -ENODEV if the device is not registered.
When called for a USB interface, dev->parent lock must be held.
try to bind driver to devices.
Parameters
Description
Walk the list of devices that the bus has on it and try to match the driver with each one. If driver_probe_device() returns 0 and the dev->driver is set, we’ve found a compatible pair.
Parameters
Description
Manually detach device from driver. When called for a USB interface, dev->parent lock must be held.
If this function is to be called with dev->parent lock held, ensure that the device’s consumers are unbound in advance or that their locks can be acquired under the dev->parent lock.
add a platform-level device with resources and platform-specific data
Parameters
Description
Returns struct platform_device pointer on success, or ERR_PTR() on error.
add a platform-level device and its resources
Parameters
Description
This function creates a simple platform device that requires minimal resource and memory management. Canned release function freeing memory allocated for the device allows drivers using such devices to be unloaded without waiting for the last reference to the device to be dropped.
This interface is primarily intended for use with legacy drivers which probe hardware directly. Because such drivers create sysfs device nodes themselves, rather than letting system infrastructure handle such device enumeration tasks, they don’t fully conform to the Linux driver model. In particular, when such drivers are built as modules, they can’t be “hotplugged”.
Returns struct platform_device pointer on success, or ERR_PTR() on error.
add a platform-level device with platform-specific data
Parameters
Description
This function creates a simple platform device that requires minimal resource and memory management. Canned release function freeing memory allocated for the device allows drivers using such devices to be unloaded without waiting for the last reference to the device to be dropped.
Returns struct platform_device pointer on success, or ERR_PTR() on error.
get a resource for a device
Parameters
get an IRQ for a device
Parameters
Count the number of IRQs a platform device uses
Parameters
Return
Number of IRQs a platform device uses or EPROBE_DEFER
get a resource for a device by name
Parameters
get an IRQ for a device by name
Parameters
add a numbers of platform devices
Parameters
destroy a platform device
Parameters
Description
Free all memory associated with a platform device. This function must _only_ be externally called in error cases. All other usage is a bug.
create a platform device
Parameters
Description
Create a platform device object which can have other objects attached to it, and which will have attached objects freed when it is released.
add resources to a platform device
Parameters
Description
Add a copy of the resources to the platform device. The memory associated with the resources will be freed when the platform device is released.
add platform-specific data to a platform device
Parameters
Description
Add a copy of platform specific data to the platform device’s platform_data pointer. The memory associated with the platform data will be freed when the platform device is released.
add built-in properties to a platform device
Parameters
Description
The function will take deep copy of properties and attach the copy to the platform device. The memory associated with properties will be freed when the platform device is released.
add a platform device to device hierarchy
Parameters
Description
This is part 2 of platform_device_register(), though may be called separately _iff_ pdev was allocated by platform_device_alloc().
remove a platform-level device
Parameters
Description
Note that this function will also release all memory- and port-based resources owned by the device (dev->resource). This function must _only_ be externally called in error cases. All other usage is a bug.
add a platform-level device
Parameters
unregister a platform-level device
Parameters
Description
Unregistration is done in 2 steps. First we release all resources and remove it from the subsystem, then we drop reference count by calling platform_device_put().
add a platform-level device with resources and platform-specific data
Parameters
Description
Returns struct platform_device pointer on success, or ERR_PTR() on error.
register a driver for platform-level devices
Parameters
unregister a driver for platform-level devices
Parameters
register driver for non-hotpluggable device
Parameters
Description
Use this instead of platform_driver_register() when you know the device is not hotpluggable and has already been registered, and you want to remove its run-once probe() infrastructure from memory after the driver has bound to the device.
One typical use for this would be with drivers for controllers integrated into system-on-chip processors, where the controller devices have been configured as part of board setup.
Note that this is incompatible with deferred probing.
Returns zero if the driver registered and bound to a device, else returns a negative error code and with the driver not registered.
register driver and create corresponding device
Parameters
Description
Use this in legacy-style modules that probe hardware directly and register a single platform device and corresponding platform driver.
Returns struct platform_device pointer on success, or ERR_PTR() on error.
register an array of platform drivers
Parameters
Description
Registers platform drivers specified by an array. On failure to register a driver, all previously registered drivers will be unregistered. Callers of this API should use platform_unregister_drivers() to unregister drivers in the reverse order.
Return
0 on success or a negative error code on failure.
unregister an array of platform drivers
Parameters
Description
Unegisters platform drivers specified by an array. This is typically used to complement an earlier call to platform_register_drivers(). Drivers are unregistered in the reverse order in which they were registered.
device iterator.
Parameters
Description
Iterate over bus‘s list of devices, and call fn for each, passing it data. If start is not NULL, we use that device to begin iterating from.
We check the return of fn each time. If it returns anything other than 0, we break out and return that value.
NOTE
The device that returns a non-zero value is not retained in any way, nor is its refcount incremented. If the caller needs to retain this data, it should do so, and increment the reference count in the supplied callback.
device iterator for locating a particular device.
Parameters
Description
This is similar to the bus_for_each_dev() function above, but it returns a reference to a device that is ‘found’ for later use, as determined by the match callback.
The callback should return 0 if the device doesn’t match and non-zero if it does. If the callback returns non-zero, this function will return to the caller and not iterate over any more devices.
device iterator for locating a particular device of a specific name
Parameters
Description
This is similar to the bus_find_device() function above, but it handles searching by a name automatically, no need to write another strcmp matching function.
find a device with a specific enumeration number
Parameters
Description
Check the hint’s next object and if it is a match return it directly, otherwise, fall back to a full list search. Either way a reference for the returned object is taken.
driver iterator
Parameters
Description
This is nearly identical to the device iterator above. We iterate over each driver that belongs to bus, and call fn for each. If fn returns anything but 0, we break out and return it. If start is not NULL, we use it as the head of the list.
NOTE
we don’t return the driver that returns a non-zero value, nor do we leave the reference count incremented for that driver. If the caller needs to know that info, it must set it in the callback. It must also be sure to increment the refcount so it doesn’t disappear before returning to the caller.
Parameters
Description
This function will look for devices on the bus with no driver attached and rescan it against existing drivers to see if it matches any by calling device_attach() for the unbound devices.
Parameters
Description
This function detaches the attached driver (if any) for the given device and restarts the driver probing process. It is intended to use if probing criteria changed during a devices lifetime and driver attachment should change accordingly.
Parameters
Description
Once we have that, we register the bus with the kobject infrastructure, then register the children subsystems it has: the devices and drivers that belong to the subsystem.
Parameters
Description
Unregister the child subsystems and the bus itself. Finally, we call bus_put() to release the refcount
initialize subsys device iterator
Parameters
Description
Initialize subsys iterator iter such that it iterates over devices of subsys. If start is set, the list iteration will start there, otherwise if it is NULL, the iteration starts at the beginning of the list.
Parameters
Description
Proceed iter to the next device and return it. Returns NULL if iteration is complete.
The returned device is referenced and won’t be released till iterator is proceed to the next device or exited. The caller is free to do whatever it wants to do with the device including calling back into subsys code.
finish iteration
Parameters
Description
Finish an iteration. Always call this function after iteration is complete whether the iteration ran till the end or not.
register a subsystem at /sys/devices/system/
Parameters
Description
All ‘system’ subsystems have a /sys/devices/system/<name> root device with the name of the subsystem. The root device can carry subsystem- wide attributes. All registered devices are below this single root device and are named after the subsystem with a simple enumeration number appended. The registered devices are not explicitly named; only ‘id’ in the device needs to be set.
Do not use this interface for anything new, it exists for compatibility with bad ideas only. New subsystems should use plain subsystems; and add the subsystem-wide attributes should be added to the subsystem directory itself and not some create fake root-device placed in /sys/devices/system/<name>.
register a subsystem at /sys/devices/virtual/
Parameters
Description
All ‘virtual’ subsystems have a /sys/devices/system/<name> root device with the name of the subystem. The root device can carry subsystem-wide attributes. All registered devices are below this single root device. There’s no restriction on device naming. This is for kernel software constructs which need sysfs interface.
try to allocate memory from the per-device coherent area
Parameters
Description
This function should be only called from per-arch dma_alloc_coherent() to support allocation from per-device coherent memory pools.
Returns 0 if dma_alloc_coherent should continue with allocating from generic memory areas, or !0 if dma_alloc_coherent should return ret.
try to free the memory allocated from per-device coherent memory pool
Parameters
Description
This checks whether the memory was allocated from the per-device coherent memory pool and if so, releases that memory.
Returns 1 if we correctly released the memory, or 0 if dma_release_coherent() should proceed with releasing memory from generic pools.
try to mmap the memory allocated from per-device coherent memory pool to userspace
Parameters
Description
This checks whether the memory was allocated from the per-device coherent memory pool and if so, maps that memory to the provided vma.
Returns 1 if we correctly mapped the memory, or 0 if the caller should proceed with mapping memory from generic pools.
Managed dma_alloc_coherent()
Parameters
Description
Managed dma_alloc_coherent(). Memory allocated using this function will be automatically released on driver detach.
Return
Pointer to allocated memory on success, NULL on failure.
Managed dma_free_coherent()
Parameters
Description
Managed dma_free_coherent().
Managed dma_alloc_noncoherent()
Parameters
Description
Managed dma_alloc_noncoherent(). Memory allocated using this function will be automatically released on driver detach.
Return
Pointer to allocated memory on success, NULL on failure.
Managed dma_free_noncoherent()
Parameters
Description
Managed dma_free_noncoherent().
Managed dma_declare_coherent_memory()
Parameters
Description
Managed dma_declare_coherent_memory().
Return
0 on success, -errno on failure.
Parameters
Description
Managed dmam_release_declared_memory().
adds a pnp protocol to the pnp layer
Parameters
Description
Ex protocols: ISAPNP, PNPBIOS, etc
removes a pnp protocol from the pnp layer
Parameters
Searches for a PnP device under the specified card
Parameters
call this when the driver no longer needs the device
Parameters
registers a PnP card driver with the PnP Layer
Parameters
unregisters a PnP card driver from the PnP Layer
Parameters
adds an EISA id to the specified device
Parameters
low-level start of the PnP device
Parameters
Description
assumes that resources have already been allocated
low-level disable of the PnP device
Parameters
Description
does not free resources
activates a PnP device for use
Parameters
Description
does not validate or set resources so be careful.
disables device
Parameters
Description
inform the correct pnp protocol so that resources can be used by other devices
Determines if a device is active based on its current resources
Parameters
Parameters
register a new userspace IO device
Parameters
Description
returns zero on success or a negative error code.
Parameters
description of a UIO memory region
Definition
struct uio_mem {
const char * name;
phys_addr_t addr;
resource_size_t size;
int memtype;
void __iomem * internal_addr;
struct uio_map * map;
};
Members
description of a UIO port region
Definition
struct uio_port {
const char * name;
unsigned long start;
unsigned long size;
int porttype;
struct uio_portio * portio;
};
Members
UIO device capabilities
Definition
struct uio_info {
struct uio_device * uio_dev;
const char * name;
const char * version;
struct uio_mem mem[MAX_UIO_MAPS];
struct uio_port port[MAX_UIO_PORT_REGIONS];
long irq;
unsigned long irq_flags;
void * priv;
irqreturn_t (* handler) (int irq, struct uio_info *dev_info);
int (* mmap) (struct uio_info *info, struct vm_area_struct *vma);
int (* open) (struct uio_info *info, struct inode *inode);
int (* release) (struct uio_info *info, struct inode *inode);
int (* irqcontrol) (struct uio_info *info, s32 irq_on);
};
Members