Thread (13 messages) 13 messages, 4 authors, 2021-02-19

Re: [PATCH] of: error: 'const struct kimage' has no member named 'arch'

From: Rob Herring <robh@kernel.org>
Date: 2021-02-19 14:18:12
Also in: linux-arm-kernel, linux-integrity, linuxppc-dev, lkml

On Thu, Feb 18, 2021 at 8:53 PM Lakshmi Ramasubramanian
[off-list ref] wrote:
On 2/18/21 5:13 PM, Thiago Jung Bauermann wrote:
quoted
Lakshmi Ramasubramanian [off-list ref] writes:
quoted
On 2/18/21 4:07 PM, Mimi Zohar wrote:

Hi Mimi,
quoted
On Thu, 2021-02-18 at 14:33 -0800, Lakshmi Ramasubramanian wrote:
quoted
of_kexec_alloc_and_setup_fdt() defined in drivers/of/kexec.c builds
a new device tree object that includes architecture specific data
for kexec system call.  This should be defined only if the architecture
being built defines kexec architecture structure "struct kimage_arch".

Define a new boolean config OF_KEXEC that is enabled if
CONFIG_KEXEC_FILE and CONFIG_OF_FLATTREE are enabled, and
the architecture is arm64 or powerpc64.  Build drivers/of/kexec.c
if CONFIG_OF_KEXEC is enabled.

Signed-off-by: Lakshmi Ramasubramanian <redacted>
Fixes: 33488dc4d61f ("of: Add a common kexec FDT setup function")
Reported-by: kernel test robot <redacted>
---
   drivers/of/Kconfig  | 6 ++++++
   drivers/of/Makefile | 7 +------
   2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 18450437d5d5..f2e8fa54862a 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -100,4 +100,10 @@ config OF_DMA_DEFAULT_COHERENT
           # arches should select this if DMA is coherent by default for OF devices
           bool
   +config OF_KEXEC
+  bool
+  depends on KEXEC_FILE
+  depends on OF_FLATTREE
+  default y if ARM64 || PPC64
+
   endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index c13b982084a3..287579dd1695 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -13,11 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
   obj-$(CONFIG_OF_RESOLVE)  += resolver.o
   obj-$(CONFIG_OF_OVERLAY) += overlay.o
   obj-$(CONFIG_OF_NUMA) += of_numa.o
-
-ifdef CONFIG_KEXEC_FILE
-ifdef CONFIG_OF_FLATTREE
-obj-y     += kexec.o
-endif
-endif
+obj-$(CONFIG_OF_KEXEC) += kexec.o
     obj-$(CONFIG_OF_UNITTEST) += unittest-data/
Is it possible to reuse CONFIG_HAVE_IMA_KEXEC here?
For ppc64 CONFIG_HAVE_IMA_KEXEC is selected when CONFIG_KEXEC_FILE is enabled.
So I don't see a problem in reusing CONFIG_HAVE_IMA_KEXEC for ppc.

But for arm64, CONFIG_HAVE_IMA_KEXEC is enabled in the final patch in the patch
set (the one for carrying forward IMA log across kexec for arm64). arm64 calls
of_kexec_alloc_and_setup_fdt() prior to enabling CONFIG_HAVE_IMA_KEXEC and hence
breaks the build for arm64.
One problem is that I believe that this patch won't placate the robot,
because IIUC it generates config files at random and this change still
allows hppa and s390 to enable CONFIG_OF_KEXEC.
I enabled CONFIG_OF_KEXEC for s390. With my patch applied,
CONFIG_OF_KEXEC is removed. So I think the robot enabling this config
would not be a problem.
quoted
Perhaps a new CONFIG_HAVE_KIMAGE_ARCH option? Not having that option
would still allow building kexec.o, but would be used inside kexec.c to
avoid accessing kimage.arch members.
I think this is a good idea - a new CONFIG_HAVE_KIMAGE_ARCH, which will
be selected by arm64 and ppc for now. I tried this, and it fixes the
build issue.

Although, the name for the new config can be misleading since PARISC,
for instance, also defines "struct kimage_arch". Perhaps,
CONFIG_HAVE_ELF_KIMAGE_ARCH since of_kexec_alloc_and_setup_fdt() is
accessing ELF specific fields in "struct kimage_arch"?

Rob/Mimi - please let us know which approach you think is better.
I'd just move the fields to kimage.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help