^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Platform Devices and Drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) See <linux/platform_device.h> for the driver model interface to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) platform bus: platform_device, and platform_driver. This pseudo-bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) is used to connect devices on busses with minimal infrastructure,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) like those used to integrate peripherals on many system-on-chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) processors, or some "legacy" PC interconnects; as opposed to large
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) formally specified ones like PCI or USB.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) Platform devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) ~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) Platform devices are devices that typically appear as autonomous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) entities in the system. This includes legacy port-based devices and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) host bridges to peripheral buses, and most controllers integrated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) into system-on-chip platforms. What they usually have in common
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) is direct addressing from a CPU bus. Rarely, a platform_device will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) be connected through a segment of some other kind of bus; but its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) registers will still be directly addressable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) Platform devices are given a name, used in driver binding, and a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) list of resources such as addresses and IRQs::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) struct platform_device {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) const char *name;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) u32 id;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) struct device dev;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) u32 num_resources;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) struct resource *resource;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) Platform drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) ~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) Platform drivers follow the standard driver model convention, where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) discovery/enumeration is handled outside the drivers, and drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) provide probe() and remove() methods. They support power management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) and shutdown notifications using the standard conventions::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) struct platform_driver {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) int (*probe)(struct platform_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) int (*remove)(struct platform_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) void (*shutdown)(struct platform_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) int (*suspend)(struct platform_device *, pm_message_t state);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) int (*suspend_late)(struct platform_device *, pm_message_t state);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) int (*resume_early)(struct platform_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) int (*resume)(struct platform_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) struct device_driver driver;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) Note that probe() should in general verify that the specified device hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) actually exists; sometimes platform setup code can't be sure. The probing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) can use device resources, including clocks, and device platform_data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Platform drivers register themselves the normal way::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) int platform_driver_register(struct platform_driver *drv);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) Or, in common situations where the device is known not to be hot-pluggable,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) the probe() routine can live in an init section to reduce the driver's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) runtime memory footprint::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) int platform_driver_probe(struct platform_driver *drv,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) int (*probe)(struct platform_device *))
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) Kernel modules can be composed of several platform drivers. The platform core
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) provides helpers to register and unregister an array of drivers::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) int __platform_register_drivers(struct platform_driver * const *drivers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) unsigned int count, struct module *owner);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) void platform_unregister_drivers(struct platform_driver * const *drivers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) unsigned int count);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) If one of the drivers fails to register, all drivers registered up to that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) point will be unregistered in reverse order. Note that there is a convenience
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) macro that passes THIS_MODULE as owner parameter::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) #define platform_register_drivers(drivers, count)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Device Enumeration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) ~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) As a rule, platform specific (and often board-specific) setup code will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) register platform devices::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) int platform_device_register(struct platform_device *pdev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) int platform_add_devices(struct platform_device **pdevs, int ndev);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) The general rule is to register only those devices that actually exist,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) but in some cases extra devices might be registered. For example, a kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) might be configured to work with an external network adapter that might not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) be populated on all boards, or likewise to work with an integrated controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) that some boards might not hook up to any peripherals.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) In some cases, boot firmware will export tables describing the devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) that are populated on a given board. Without such tables, often the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) only way for system setup code to set up the correct devices is to build
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) a kernel for a specific target board. Such board-specific kernels are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) common with embedded and custom systems development.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) In many cases, the memory and IRQ resources associated with the platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) device are not enough to let the device's driver work. Board setup code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) will often provide additional information using the device's platform_data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) field to hold additional information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) Embedded systems frequently need one or more clocks for platform devices,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) which are normally kept off until they're actively needed (to save power).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) System setup also associates those clocks with the device, so that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) calls to clk_get(&pdev->dev, clock_name) return them as needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) Legacy Drivers: Device Probing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) Some drivers are not fully converted to the driver model, because they take
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) on a non-driver role: the driver registers its platform device, rather than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) leaving that for system infrastructure. Such drivers can't be hotplugged
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) or coldplugged, since those mechanisms require device creation to be in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) different system component than the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) The only "good" reason for this is to handle older system designs which, like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) configuration. Newer systems have largely abandoned that model, in favor of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) bus-level support for dynamic configuration (PCI, USB), or device tables
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) provided by the boot firmware (e.g. PNPACPI on x86). There are too many
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) conflicting options about what might be where, and even educated guesses by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) an operating system will be wrong often enough to make trouble.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) This style of driver is discouraged. If you're updating such a driver,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) please try to move the device enumeration to a more appropriate location,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) outside the driver. This will usually be cleanup, since such drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) tend to already have "normal" modes, such as ones using device nodes that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) were created by PNP or by platform device setup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) None the less, there are some APIs to support such legacy drivers. Avoid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) using these calls except with such hotplug-deficient drivers::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) struct platform_device *platform_device_alloc(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) const char *name, int id);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) You can use platform_device_alloc() to dynamically allocate a device, which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) you will then initialize with resources and platform_device_register().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) A better solution is usually::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) struct platform_device *platform_device_register_simple(
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) const char *name, int id,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) struct resource *res, unsigned int nres);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) You can use platform_device_register_simple() as a one-step call to allocate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) and register a device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) Device Naming and Driver Binding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) The platform_device.dev.bus_id is the canonical name for the devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) It's built from two components:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) * platform_device.name ... which is also used to for driver matching.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) * platform_device.id ... the device instance number, or else "-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) to indicate there's only one.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) These are concatenated, so name/id "serial"/0 indicates bus_id "serial.0", and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) "serial/3" indicates bus_id "serial.3"; both would use the platform_driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) and use the platform_driver called "my_rtc".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) Driver binding is performed automatically by the driver core, invoking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) driver probe() after finding a match between device and driver. If the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) probe() succeeds, the driver and device are bound as usual. There are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) three different ways to find such a match:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) - Whenever a device is registered, the drivers for that bus are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) checked for matches. Platform devices should be registered very
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) early during system boot.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) - When a driver is registered using platform_driver_register(), all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) unbound devices on that bus are checked for matches. Drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) usually register later during booting, or by module loading.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) - Registering a driver using platform_driver_probe() works just like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) using platform_driver_register(), except that the driver won't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) be probed later if another device registers. (Which is OK, since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) this interface is only for use with non-hotpluggable devices.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) Early Platform Devices and Drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) The early platform interfaces provide platform data to platform device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) drivers early on during the system boot. The code is built on top of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) early_param() command line parsing and can be executed very early on.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) Example: "earlyprintk" class early serial console in 6 steps
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) 1. Registering early platform device data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) The architecture code registers platform device data using the function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) early_platform_add_devices(). In the case of early serial console this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) should be hardware configuration for the serial port. Devices registered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) at this point will later on be matched against early platform drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) 2. Parsing kernel command line
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) The architecture code calls parse_early_param() to parse the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) command line. This will execute all matching early_param() callbacks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) User specified early platform devices will be registered at this point.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) For the early serial console case the user can specify port on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) kernel command line as "earlyprintk=serial.0" where "earlyprintk" is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) the class string, "serial" is the name of the platform driver and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) 0 is the platform device id. If the id is -1 then the dot and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) id can be omitted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) 3. Installing early platform drivers belonging to a certain class
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) The architecture code may optionally force registration of all early
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) platform drivers belonging to a certain class using the function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) early_platform_driver_register_all(). User specified devices from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) step 2 have priority over these. This step is omitted by the serial
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) driver example since the early serial driver code should be disabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) unless the user has specified port on the kernel command line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) 4. Early platform driver registration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) Compiled-in platform drivers making use of early_platform_init() are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) automatically registered during step 2 or 3. The serial driver example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) should use early_platform_init("earlyprintk", &platform_driver).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) 5. Probing of early platform drivers belonging to a certain class
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) The architecture code calls early_platform_driver_probe() to match
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) registered early platform devices associated with a certain class with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) registered early platform drivers. Matched devices will get probed().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) This step can be executed at any point during the early boot. As soon
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) as possible may be good for the serial port case.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) 6. Inside the early platform driver probe()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) The driver code needs to take special care during early boot, especially
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) when it comes to memory allocation and interrupt registration. The code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) in the probe() function can use is_early_platform_device() to check if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) it is called at early platform device or at the regular platform device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) time. The early serial driver performs register_console() at this point.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) For further information, see <linux/platform_device.h>.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags