On Wed, Nov 18, 2015 at 02:04:24PM +0100, François Revol wrote:
On 17/11/2015 23:14, Rob Herring wrote:
On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
On 15/11/2015 03:07, Rob Herring wrote:
We generally don't want DT docs to depend on other kernel documentation.
DT docs do not contain a copy of the data sheets, either. There is no reason to say how to use the device (and even then, only doing so partially) in the DT docs.
The difference is datasheets apply to all OS's, kernel documentation does not. In theory at least this could be used for other OS's, right?
Would be nice indeed, as it's part of their intended purpose.
For now we have to shoehorn things into linux-only stuff (like initrd) because well, nobody cares enough about NetBSD to compile U-Boot with its internal API, so let alone adding custom Haiku code.
And of course, for things linux doesn't care about (like framebuffer description) then we're stuck trying to guess where it's at and writing drivers for our bootloader.
So if at least people were considering they aren't the only users of this, that'd make life better for everyone.
Perhaps QEMU is the right place to thoroughly describe this and DT and sysfs docs can refer to it.
The brilliant idea of FDT was that we could have a canonical source and blob for it where people could send patches, but of course Linux and BSD freaks disagreed, so you now find Linux-flavoured DTs for rPi and other things, as well as BSD versions.
Please, at least get the binding documentation for this unique and usable for everyone!
That would be 'docs/specs/fw_cfg.txt' in the QEMU source tree. I will avoid cut'n'pasting anything from there into either the proposed Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg (leaving only the sysfs specific bits in there), and also remove any redundant bits from Documentation/devicetree/bindings/arm/fw-cfg.txt. I'm inclined to add (in v5) a mention of 'qemu:docs/specs/fw_cfg.txt' to both the proposed fw_cfg sysfs doc file, and to the existing fw_cfg arm/dt node doc file, unless I get strong objections against doing so... :) Thanks, --Gabriel