| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sat, 12 Mar 2011 22:32:35 +0000 From: Andy Green <andy@...mcat.com> To: linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org Cc: patches@...aro.org, Andy Green <andy.green@...aro.org> Subject: [RFC PATCH 4/4] PLATFORM: Add some documentation to platform docs about async platform_data Signed-off-by: Andy Green <andy.green@...aro.org> --- 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists