diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2016-03-17 20:38:00 (GMT) |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-03-17 20:38:00 (GMT) |
commit | 1a4ab084afaa8e5405a3e22aca21478ee3ca5d59 (patch) | |
tree | fe559fa3377199d335ab477e86050f34d76c13f0 /Documentation | |
parent | 45cb5230f862d10209b83e488b20916555d70c55 (diff) | |
parent | 112d125a89479519efc437b2961b8d4a98761c1b (diff) | |
download | linux-1a4ab084afaa8e5405a3e22aca21478ee3ca5d59.tar.xz |
Merge tag 'driver-core-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Just a few patches this time around for the 4.6-rc1 merge window.
Largest is a new firmware driver, but there are some other updates to
the driver core in here as well, the shortlog has the details.
All have been in linux-next for a while with no reported issues"
* tag 'driver-core-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
Revert "driver-core: platform: probe of-devices only using list of compatibles"
firmware: qemu config needs I/O ports
firmware: qemu_fw_cfg.c: fix typo FW_CFG_DATA_OFF
driver-core: platform: probe of-devices only using list of compatibles
driver-core: platform: fix typo in documentation for multi-driver helper
component: remove impossible condition
drivers: dma-coherent: simplify dma_init_coherent_memory return value
devicetree: update documentation for fw_cfg ARM bindings
firmware: create directory hierarchy for sysfs fw_cfg entries
firmware: introduce sysfs driver for QEMU's fw_cfg device
kobject: export kset_find_obj() for module use
driver core: bus: use to_subsys_private and to_device_private_bus
driver core: bus: use list_for_each_entry*
debugfs: Add stub function for debugfs_create_automount().
kernfs: make kernfs_walk_ns() use kernfs_pr_cont_buf[]
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg | 100 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/fw-cfg.txt | 38 | ||||
-rw-r--r-- | Documentation/driver-model/platform.txt | 2 |
3 files changed, 103 insertions, 37 deletions
diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg new file mode 100644 index 0000000..011dda4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg @@ -0,0 +1,100 @@ +What: /sys/firmware/qemu_fw_cfg/ +Date: August 2015 +Contact: Gabriel Somlo <somlo@cmu.edu> +Description: + Several different architectures supported by QEMU (x86, arm, + sun4*, ppc/mac) are provisioned with a firmware configuration + (fw_cfg) device, originally intended as a way for the host to + provide configuration data to the guest firmware. Starting + with QEMU v2.4, arbitrary fw_cfg file entries may be specified + by the user on the command line, which makes fw_cfg additionally + useful as an out-of-band, asynchronous mechanism for providing + configuration data to the guest userspace. + + The authoritative guest-side hardware interface documentation + to the fw_cfg device can be found in "docs/specs/fw_cfg.txt" + in the QEMU source tree. + + === SysFS fw_cfg Interface === + + The fw_cfg sysfs interface described in this document is only + intended to display discoverable blobs (i.e., those registered + with the file directory), as there is no way to determine the + presence or size of "legacy" blobs (with selector keys between + 0x0002 and 0x0018) programmatically. + + All fw_cfg information is shown under: + + /sys/firmware/qemu_fw_cfg/ + + The only legacy blob displayed is the fw_cfg device revision: + + /sys/firmware/qemu_fw_cfg/rev + + --- Discoverable fw_cfg blobs by selector key --- + + All discoverable blobs listed in the fw_cfg file directory are + displayed as entries named after their unique selector key + value, e.g.: + + /sys/firmware/qemu_fw_cfg/by_key/32 + /sys/firmware/qemu_fw_cfg/by_key/33 + /sys/firmware/qemu_fw_cfg/by_key/34 + ... + + Each such fw_cfg sysfs entry has the following values exported + as attributes: + + name : The 56-byte nul-terminated ASCII string used as the + blob's 'file name' in the fw_cfg directory. + size : The length of the blob, as given in the fw_cfg + directory. + key : The value of the blob's selector key as given in the + fw_cfg directory. This value is the same as used in + the parent directory name. + raw : The raw bytes of the blob, obtained by selecting the + entry via the control register, and reading a number + of bytes equal to the blob size from the data + register. + + --- Listing fw_cfg blobs by file name --- + + While the fw_cfg device does not impose any specific naming + convention on the blobs registered in the file directory, + QEMU developers have traditionally used path name semantics + to give each blob a descriptive name. For example: + + "bootorder" + "genroms/kvmvapic.bin" + "etc/e820" + "etc/boot-fail-wait" + "etc/system-states" + "etc/table-loader" + "etc/acpi/rsdp" + "etc/acpi/tables" + "etc/smbios/smbios-tables" + "etc/smbios/smbios-anchor" + ... + + In addition to the listing by unique selector key described + above, the fw_cfg sysfs driver also attempts to build a tree + of directories matching the path name components of fw_cfg + blob names, ending in symlinks to the by_key entry for each + "basename", as illustrated below (assume current directory is + /sys/firmware): + + qemu_fw_cfg/by_name/bootorder -> ../by_key/38 + qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35 + qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41 + ... + + Construction of the directory tree and symlinks is done on a + "best-effort" basis, as there is no guarantee that components + of fw_cfg blob names are always "well behaved". I.e., there is + the possibility that a symlink (basename) will conflict with + a dirname component of another fw_cfg blob, in which case the + creation of the offending /sys/firmware/qemu_fw_cfg/by_name + entry will be skipped. + + The authoritative list of entries will continue to be found + under the /sys/firmware/qemu_fw_cfg/by_key directory. diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt b/Documentation/devicetree/bindings/arm/fw-cfg.txt index 953fb64..fd54e1d 100644 --- a/Documentation/devicetree/bindings/arm/fw-cfg.txt +++ b/Documentation/devicetree/bindings/arm/fw-cfg.txt @@ -11,43 +11,9 @@ QEMU exposes the control and data register to ARM guests as memory mapped registers; their location is communicated to the guest's UEFI firmware in the DTB that QEMU places at the bottom of the guest's DRAM. -The guest writes a selector value (a key) to the selector register, and then -can read the corresponding data (produced by QEMU) via the data register. If -the selected entry is writable, the guest can rewrite it through the data -register. +The authoritative guest-side hardware interface documentation to the fw_cfg +device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree. -The selector register takes keys in big endian byte order. - -The data register allows accesses with 8, 16, 32 and 64-bit width (only at -offset 0 of the register). Accesses larger than a byte are interpreted as -arrays, bundled together only for better performance. The bytes constituting -such a word, in increasing address order, correspond to the bytes that would -have been transferred by byte-wide accesses in chronological order. - -The interface allows guest firmware to download various parameters and blobs -that affect how the firmware works and what tables it installs for the guest -OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and -initrd images for direct kernel booting, virtual machine UUID, SMP information, -virtual NUMA topology, and so on. - -The authoritative registry of the valid selector values and their meanings is -the QEMU source code; the structure of the data blobs corresponding to the -individual key values is also defined in the QEMU source code. - -The presence of the registers can be verified by selecting the "signature" blob -with key 0x0000, and reading four bytes from the data register. The returned -signature is "QEMU". - -The outermost protocol (involving the write / read sequences of the control and -data registers) is expected to be versioned, and/or described by feature bits. -The interface revision / feature bitmap can be retrieved with key 0x0001. The -blob to be read from the data register has size 4, and it is to be interpreted -as a uint32_t value in little endian byte order. The current value -(corresponding to the above outer protocol) is zero. - -The guest kernel is not expected to use these registers (although it is -certainly allowed to); the device tree bindings are documented here because -this is where device tree bindings reside in general. Required properties: diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt index e456696..9d9e47d 100644 --- a/Documentation/driver-model/platform.txt +++ b/Documentation/driver-model/platform.txt @@ -75,7 +75,7 @@ If one of the drivers fails to register, all drivers registered up to that point will be unregistered in reverse order. Note that there is a convenience macro that passes THIS_MODULE as owner parameter: - #define platform_register_driver(drivers, count) + #define platform_register_drivers(drivers, count) Device Enumeration |