From: "Gabriel L. Somlo" <somlo@cmu.edu>
To: gregkh@linuxfoundation.org, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
arnd@arndb.de, lersek@redhat.com, ralf@linux-mips.org,
rmk+kernel@arm.linux.org.uk, eric@anholt.net,
hanjun.guo@linaro.org, zajec5@gmail.com, sudeep.holla@arm.com,
agross@codeaurora.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Cc: qemu-devel@nongnu.org, mst@redhat.com, imammedo@redhat.com,
peter.maydell@linaro.org, leif.lindholm@linaro.org,
ard.biesheuvel@linaro.org, pbonzini@redhat.com,
kraxel@redhat.com, ehabkost@redhat.com, luto@amacapital.net,
stefanha@gmail.com, revol@free.fr, matt@codeblueprint.co.uk,
rth@twiddle.net
Subject: [PATCH v8 4/4] devicetree: update documentation for fw_cfg ARM bindings
Date: Thu, 28 Jan 2016 09:23:14 -0500 [thread overview]
Message-ID: <1453990994-17801-5-git-send-email-somlo@cmu.edu> (raw)
In-Reply-To: <1453990994-17801-1-git-send-email-somlo@cmu.edu>
From: Gabriel Somlo <somlo@cmu.edu>
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Cc: Laszlo Ersek <lersek@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
Documentation/devicetree/bindings/arm/fw-cfg.txt | 38 ++----------------------
1 file changed, 2 insertions(+), 36 deletions(-)
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:
--
2.4.3
next prev parent reply other threads:[~2016-01-28 14:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 14:23 [PATCH v8 0/4] SysFS driver for QEMU fw_cfg device Gabriel L. Somlo
2016-01-28 14:23 ` [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's " Gabriel L. Somlo
2016-02-21 8:30 ` Michael S. Tsirkin
2016-02-21 13:06 ` Gabriel L. Somlo
2016-02-21 13:10 ` Michael S. Tsirkin
2016-02-21 17:20 ` Gabriel L. Somlo
2016-02-21 13:14 ` Michael S. Tsirkin
2016-02-22 20:14 ` Michael S. Tsirkin
2016-02-22 20:26 ` Gabriel L. Somlo
2016-02-23 5:07 ` Michael S. Tsirkin
2016-02-23 13:47 ` Gabriel L. Somlo
2016-02-23 14:14 ` Michael S. Tsirkin
2016-02-24 0:03 ` Gabriel L. Somlo
2016-01-28 14:23 ` [PATCH v8 2/4] kobject: export kset_find_obj() for module use Gabriel L. Somlo
2016-02-07 7:24 ` Greg KH
2016-02-07 14:27 ` Gabriel L. Somlo
2016-01-28 14:23 ` [PATCH v8 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries Gabriel L. Somlo
2016-01-28 14:23 ` Gabriel L. Somlo [this message]
2016-02-03 22:47 ` [PATCH v8 0/4] SysFS driver for QEMU fw_cfg device Matt Fleming
2016-02-10 1:38 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453990994-17801-5-git-send-email-somlo@cmu.edu \
--to=somlo@cmu.edu \
--cc=agross@codeaurora.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=ehabkost@redhat.com \
--cc=eric@anholt.net \
--cc=galak@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=hanjun.guo@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=imammedo@redhat.com \
--cc=kraxel@redhat.com \
--cc=leif.lindholm@linaro.org \
--cc=lersek@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mark.rutland@arm.com \
--cc=matt@codeblueprint.co.uk \
--cc=mst@redhat.com \
--cc=pawel.moll@arm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=ralf@linux-mips.org \
--cc=revol@free.fr \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=robh+dt@kernel.org \
--cc=rth@twiddle.net \
--cc=stefanha@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).