[RFC PATCH 4/4] PLATFORM: Add some documentation to platform docsabout async platform_data

[Andy Green]

Signed-off-by: Andy Green <andy.green@xxxxxxxxxx>
---

 Documentation/driver-model/platform.txt |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt
index 41f4163..0c34156 100644
--- a/Documentation/driver-model/platform.txt
+++ b/Documentation/driver-model/platform.txt
@@ -96,6 +96,31 @@ System setup also associates those clocks with the device, so that that
 calls to clk_get(&pdev->dev, clock_name) return them as needed.
 
 
+Providing platform_data to onboard devices on asynchronously probed buses
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Some boards have fixed onboard assets that would normally be dealt with
+by using plaform_data set in the usual way in the board definition file,
+but cannot directly do so because they are on a bus that is probed
+asynchronously.  For emebedded devices, often the broard definition
+file is adding platform devices for the buses involved, like USB host
+and gadget, in a fixed order using platform_add_devices(), so the device
+path of these fixed soldered-on-the-board assets is deterministic.
+
+For buses and devices that are named deterministically at boot-time,
+you can define platform_data that binds to these devices when they are
+probed by declaring a map of device paths to platform_data in your
+board definition file before adding the bus platform devices, using
+
+	void platform_register_async_platform_data(
+		struct platform_async_platform_data *map, int count);
+
+Buses that participate in this scheme will then check this mapping list
+for corresponding platform_data as they are probed and apply it
+automatically.  An example device path mapping is
+
+	"usb1/1-1/1-1.1"
+
+
 Legacy Drivers:  Device Probing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Some drivers are not fully converted to the driver model, because they take

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/