dm: treewide: Rename ofdata_to_platdata() to of_to_plat()
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
Signed-off-by: Simon Glass <sjg@chromium.org>
diff --git a/doc/driver-model/design.rst b/doc/driver-model/design.rst
index d552f46..b0da3ad 100644
--- a/doc/driver-model/design.rst
+++ b/doc/driver-model/design.rst
@@ -333,11 +333,11 @@
* bind - make the driver model aware of a device (bind it to its driver)
* unbind - make the driver model forget the device
- * ofdata_to_platdata - convert device tree data to plat - see later
+ * of_to_plat - convert device tree data to plat - see later
* probe - make a device ready for use
* remove - remove a device so it cannot be used until probed again
-The sequence to get a device to work is bind, ofdata_to_platdata (if using
+The sequence to get a device to work is bind, of_to_plat (if using
device tree) and probe.
@@ -449,23 +449,23 @@
.. code-block:: c
.plat_auto = sizeof(struct dm_test_pdata),
- .ofdata_to_platdata = testfdt_ofdata_to_platdata,
+ .of_to_plat = testfdt_of_to_plat,
The 'auto' feature allowed space for the plat to be allocated
-and zeroed before the driver's ofdata_to_platdata() method is called. The
-ofdata_to_platdata() method, which the driver write supplies, should parse
+and zeroed before the driver's of_to_plat() method is called. The
+of_to_plat() method, which the driver write supplies, should parse
the device tree node for this device and place it in dev->plat. Thus
when the probe method is called later (to set up the device ready for use)
the platform data will be present.
-Note that both methods are optional. If you provide an ofdata_to_platdata
+Note that both methods are optional. If you provide an of_to_plat
method then it will be called first (during activation). If you provide a
probe method it will be called next. See Driver Lifecycle below for more
details.
If you don't want to have the plat automatically allocated then you
can leave out plat_auto. In this case you can use malloc
-in your ofdata_to_platdata (or probe) method to allocate the required memory,
+in your of_to_plat (or probe) method to allocate the required memory,
and you should free it in the remove method.
The driver model tree is intended to mirror that of the device tree. The
@@ -690,7 +690,7 @@
base address of hardware registers and parameters relating to driver
operation. This is called 'ofdata' (Open-Firmware data).
-The device's_ofdata_to_platdata() implemnents allocation and reading of
+The device's of_to_plat() implemnents allocation and reading of
plat. A parent's ofdata is always read before a child.
The steps are:
@@ -719,7 +719,7 @@
space. The controller can hold information about the USB state of each
of its children.
- 5. If the driver provides an ofdata_to_platdata() method, then this is
+ 5. If the driver provides an of_to_plat() method, then this is
called to convert the device tree data into platform data. This should
do various calls like dev_read_u32(dev, ...) to access the node and store
the resulting information into dev->plat. After this point, the device
@@ -728,9 +728,9 @@
in the plat structure. Typically you will use the
plat_auto feature to specify the size of the platform data
structure, and U-Boot will automatically allocate and zero it for you before
- entry to ofdata_to_platdata(). But if not, you can allocate it yourself in
- ofdata_to_platdata(). Note that it is preferable to do all the device tree
- decoding in ofdata_to_platdata() rather than in probe(). (Apart from the
+ entry to of_to_plat(). But if not, you can allocate it yourself in
+ of_to_plat(). Note that it is preferable to do all the device tree
+ decoding in of_to_plat() rather than in probe(). (Apart from the
ugliness of mixing configuration and run-time data, one day it is possible
that U-Boot will cache platform data for devices which are regularly
de/activated).
@@ -744,7 +744,7 @@
Having probing separate from ofdata-reading helps deal with of-platdata, where
the probe() method is common to both DT/of-platdata operation, but the
-ofdata_to_platdata() method is implemented differently.
+of_to_plat() method is implemented differently.
Another case has come up where this separate is useful. Generation of ACPI
tables uses the of-platdata but does not want to probe the device. Probing
@@ -755,18 +755,18 @@
present will cause an error on probe, yet we still must tell Linux about
the SD card connector in case it is used while Linux is running.
-It is important that the ofdata_to_platdata() method does not actually probe
+It is important that the of_to_plat() method does not actually probe
the device itself. However there are cases where other devices must be probed
-in the ofdata_to_platdata() method. An example is where a device requires a
+in the of_to_plat() method. An example is where a device requires a
GPIO for it to operate. To select a GPIO obviously requires that the GPIO
device is probed. This is OK when used by common, core devices such as GPIO,
clock, interrupts, reset and the like.
If your device relies on its parent setting up a suitable address space, so
that dev_read_addr() works correctly, then make sure that the parent device
-has its setup code in ofdata_to_platdata(). If it has it in the probe method,
+has its setup code in of_to_plat(). If it has it in the probe method,
then you cannot call dev_read_addr() from the child device's
-ofdata_to_platdata() method. Move it to probe() instead. Buses like PCI can
+of_to_plat() method. Move it to probe() instead. Buses like PCI can
fall afoul of this rule.
Activation/probe
@@ -847,7 +847,7 @@
happens automatically within the driver model core; or
- when plat_auto is 0, both the allocation (in probe()
- or preferably ofdata_to_platdata()) and the deallocation in remove()
+ or preferably of_to_plat()) and the deallocation in remove()
are the responsibility of the driver author.
5. The device sequence number is set to -1, meaning that it no longer