[PATCH v2 1/2] of/fdt: export fdt blob as /sys/firmware/fdt

On Wed, Nov 12, 2014 at 12:08 PM, Ard Biesheuvel
[off-list ref] wrote:

On 12 November 2014 13:01, Grant Likely [off-list ref] wrote:

quoted

On Wed, Nov 12, 2014 at 11:51 AM, Ard Biesheuvel
[off-list ref] wrote:

quoted

On 12 November 2014 12:45, Grant Likely [off-list ref] wrote:

quoted

On Tue, Nov 11, 2014 at 8:34 PM, Ard Biesheuvel
[off-list ref] wrote:

quoted

On 11 November 2014 21:08, Grant Likely [off-list ref] wrote:

quoted

On Tue, Nov 11, 2014 at 4:25 PM, Rob Herring [off-list ref] wrote:

quoted

On Tue, Nov 11, 2014 at 8:42 AM, Grant Likely [off-list ref] wrote:

quoted

On Mon, 10 Nov 2014 19:47:01 +0100
, Ard Biesheuvel [off-list ref]
 wrote:

quoted

Create a new /sys entry '/sys/firmware/fdt' to export the FDT blob
that was passed to the kernel by the bootloader. This allows userland
applications such as kexec to access the raw binary. The blob needs to
be preserved as early as possible by calling preserve_fdt().

The fact that this node does not reside under /sys/firmware/device-tree
is deliberate: FDT is also used on arm64 UEFI/ACPI systems to
communicate just the UEFI and ACPI entry points, but the FDT is never
unflattened and used to configure the system.

Signed-off-by: Ard Biesheuvel <redacted>

On further thought, nak. I want tree modifications to be treated as
bugs. Do a checksum CRC32 or check. It's simpler and it can be extended
to us an in-blob CRC when the file format gets upreved to include one.

Why? MIPS Octeon is full of them BTW. So the rule is any modifications
or fixups have to be on the unflattened tree?

That, or we require the fixups to explicitly clean up the CRC after
themselves. That will force them to be visible. Anything using the
fdt_*() write functions could potentially take care of it
automatically. That would make it immediately discoverable where
changes are being made in the tree.

Doesn't that defeat the purpose of capturing the FDT as it was passed
by the bootloader? Those fixups will be reapplied by the kexec'ed
kernel anyway.

We're always going to be in a grey area here. There are some things
that should not be passed over. For example, a framebuffer that is
passed in from firmware will no longer be valid on kexec. Right now on
arch/arm, the exynos platform fixes up the DT because the memory node
is outright /corrupt/. In the MIPS case, they do a bunch of stuff in
the kernel to figure out the hardware as configured by firmware. I
don't agree with that approach, but I would be very surprised if the
full original DT has any validity after the early boot fixups.

Well, yes, but those fixups will presumably be done on every boot,
including the kexec ones.

quoted

Early boot fixups to the .dtb are always going to be oddball cases.

OK, so generally speaking, whether the original DTB is more suitable
to be presented through /sys/firmware/fdt than the 'current' FDT
(i.e., whatever is in memory at the time the sysfs node is accessed)
is not obvious at all. So why not just do the latter?

We're now talking theoreticals. In the case you're working on
(ACPI+FDT), the FDT is generated by Grub or the EFI stub as an
intermediary format, and there isn't currently any code in your boot
path that modifies the FDT. You're arguing for a future situation
where the kernel makes a fixup that is not wanted in the second
kernel. I'm arguing that 1) I want to /know/ when that happens because
there are very few situations where it is a valid thing to do, and 2)
the likelyhood of that happening in the FDT+ACPI case is somewhere
between slim and none because you're working with an intermediary FDT,
not a real hardware description.

But do you still want the warning? Or only if you access the sysfs
node? Or just a pr_warn() perhaps rather than a full blown WARN() ?
MIPS will start seeing the warning as well even if they don't care
about what is in /sys/firmware/fdt

pr_warn() and then don't export the file in /sys/firmware/fdt. I'm
okay with the check being done once at the end of initcalls.

g.