diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/driver-model/platform.txt | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt index 19c4a6e13676..2a97320ee17f 100644 --- a/Documentation/driver-model/platform.txt +++ b/Documentation/driver-model/platform.txt | |||
@@ -96,6 +96,46 @@ System setup also associates those clocks with the device, so that that | |||
96 | calls to clk_get(&pdev->dev, clock_name) return them as needed. | 96 | calls to clk_get(&pdev->dev, clock_name) return them as needed. |
97 | 97 | ||
98 | 98 | ||
99 | Legacy Drivers: Device Probing | ||
100 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
101 | Some drivers are not fully converted to the driver model, because they take | ||
102 | on a non-driver role: the driver registers its platform device, rather than | ||
103 | leaving that for system infrastructure. Such drivers can't be hotplugged | ||
104 | or coldplugged, since those mechanisms require device creation to be in a | ||
105 | different system component than the driver. | ||
106 | |||
107 | The only "good" reason for this is to handle older system designs which, like | ||
108 | original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware | ||
109 | configuration. Newer systems have largely abandoned that model, in favor of | ||
110 | bus-level support for dynamic configuration (PCI, USB), or device tables | ||
111 | provided by the boot firmware (e.g. PNPACPI on x86). There are too many | ||
112 | conflicting options about what might be where, and even educated guesses by | ||
113 | an operating system will be wrong often enough to make trouble. | ||
114 | |||
115 | This style of driver is discouraged. If you're updating such a driver, | ||
116 | please try to move the device enumeration to a more appropriate location, | ||
117 | outside the driver. This will usually be cleanup, since such drivers | ||
118 | tend to already have "normal" modes, such as ones using device nodes that | ||
119 | were created by PNP or by platform device setup. | ||
120 | |||
121 | None the less, there are some APIs to support such legacy drivers. Avoid | ||
122 | using these calls except with such hotplug-deficient drivers. | ||
123 | |||
124 | struct platform_device *platform_device_alloc( | ||
125 | char *name, unsigned id); | ||
126 | |||
127 | You can use platform_device_alloc() to dynamically allocate a device, which | ||
128 | you will then initialize with resources and platform_device_register(). | ||
129 | A better solution is usually: | ||
130 | |||
131 | struct platform_device *platform_device_register_simple( | ||
132 | char *name, unsigned id, | ||
133 | struct resource *res, unsigned nres); | ||
134 | |||
135 | You can use platform_device_register_simple() as a one-step call to allocate | ||
136 | and register a device. | ||
137 | |||
138 | |||
99 | Device Naming and Driver Binding | 139 | Device Naming and Driver Binding |
100 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 140 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
101 | The platform_device.dev.bus_id is the canonical name for the devices. | 141 | The platform_device.dev.bus_id is the canonical name for the devices. |