Documentation/driver-api/driver-model/platform.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/driver-model/platform.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/driver-model/platform.rst
Extension
.rst
Size
11192 bytes
Lines
249
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: operation-table or driver-model contract
Status
pattern implementation candidate

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

struct device_driver driver;
	const struct platform_device_id *id_table;
	bool prevent_deferred_probe;
	bool driver_managed_dma;
  };

Note that probe() should in general verify that the specified device hardware
actually exists; sometimes platform setup code can't be sure.  The probing
can use device resources, including clocks, and device platform_data.

Platform drivers register themselves the normal way::

	int platform_driver_register(struct platform_driver *drv);

Or, in common situations where the device is known not to be hot-pluggable,
the probe() routine can live in an init section to reduce the driver's
runtime memory footprint::

	int platform_driver_probe(struct platform_driver *drv,
			  int (*probe)(struct platform_device *))

Kernel modules can be composed of several platform drivers. The platform core
provides helpers to register and unregister an array of drivers::

	int __platform_register_drivers(struct platform_driver * const *drivers,
				      unsigned int count, struct module *owner,
				      const char *mod_name);
	void platform_unregister_drivers(struct platform_driver * const *drivers,
					 unsigned int count);

If one of the drivers fails to register, all drivers registered up to that
point will be unregistered in reverse order. Note that there is a convenience
macro that passes THIS_MODULE as owner parameter::

	#define platform_register_drivers(drivers, count)


Device Enumeration
~~~~~~~~~~~~~~~~~~
As a rule, platform specific (and often board-specific) setup code will
register platform devices::

	int platform_device_register(struct platform_device *pdev);

	int platform_add_devices(struct platform_device **pdevs, int ndev);

The general rule is to register only those devices that actually exist,
but in some cases extra devices might be registered.  For example, a kernel
might be configured to work with an external network adapter that might not
be populated on all boards, or likewise to work with an integrated controller
that some boards might not hook up to any peripherals.

In some cases, boot firmware will export tables describing the devices
that are populated on a given board.   Without such tables, often the
only way for system setup code to set up the correct devices is to build
a kernel for a specific target board.  Such board-specific kernels are
common with embedded and custom systems development.

In many cases, the memory and IRQ resources associated with the platform
device are not enough to let the device's driver work.  Board setup code
will often provide additional information using the device's platform_data
field to hold additional information.

Embedded systems frequently need one or more clocks for platform devices,
which are normally kept off until they're actively needed (to save power).
System setup also associates those clocks with the device, so that
calls to clk_get(&pdev->dev, clock_name) return them as needed.


Legacy Drivers:  Device Probing

Annotation

Implementation Notes