From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Graeme Gregory <graeme.gregory@linaro.org>,
Al Stone <al.stone@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Bhupesh Sharma <bhsharma@redhat.com>,
"Baicar, Tyler" <tbaicar@codeaurora.org>,
Will Deacon <will.deacon@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
James Morse <james.morse@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Dave Young <dyoung@redhat.com>,
Kexec Mailing List <kexec@lists.infradead.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system
Date: Tue, 17 Jul 2018 14:12:23 +0900 [thread overview]
Message-ID: <20180717051222.GA11258@linaro.org> (raw)
In-Reply-To: <CAKv+Gu9PT75XTXGsh1jc5roRO_d2QYKEamq42mfbsXzmerAUzA@mail.gmail.com>
Will,
On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote:
> On 13 July 2018 at 02:34, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote:
> >> Hi Akashi,
> >>
> >> On Tue, Jul 10, 2018 at 08:42:25AM +0900, AKASHI Takahiro wrote:
> >> > This patch series is a set of bug fixes to address kexec/kdump
> >> > failures which are sometimes observed on ACPI-only system and reported
> >> > in LAK-ML before.
> >>
> >> I tried picking this up, along with Ard's fixup, but I'm seeing a build
> >> failure for allmodconfig:
> >>
> >> arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
> >> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'
> >>
> >> I didn't investigate further. Please can you fix this?
> >
> > Because CONFIG_ACPI is on and CONFIG_EFI is off.
> >
> > This can happen in allmodconfig as CONFIG_EFI depends on
> > !CONFIG_CPU_BIG_ENDIAN, which is actually on in this case.
> >
>
> Allowing both CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN to be configured
> makes no sense at all. Things will surely break if you start using BE
> memory accesses while parsing ACPI tables.
>
> Allowing CONFIG_ACPI without CONFIG_EFI makes no sense either, since
> on arm64, the only way to find the ACPI tables is through a UEFI
> configuration table.
Do you agree to this?
-Takahiro AKASHI
> > Looking at __acpi_get_mem_attributes(), since there is no information
> > available on memory attributes, what we can do at best is
> > * return PAGE_KERNEL (= cacheable) for mapped memory,
> > * return DEVICE_nGnRnE (= non-cacheable) otherwise
> > (See a hunk to be applied on top of my patch#4.)
> >
> > I think that, after applying, acpi_os_ioremap() would work almost
> > in the same way as the original before my patchset given that
> > MAP memblock attribute is used only under CONFIG_EFI for now.
> >
> > Make sense?
> >
>
> Let's keep your code as is but fix the Kconfig dependencies instead.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system
Date: Tue, 17 Jul 2018 14:12:23 +0900 [thread overview]
Message-ID: <20180717051222.GA11258@linaro.org> (raw)
In-Reply-To: <CAKv+Gu9PT75XTXGsh1jc5roRO_d2QYKEamq42mfbsXzmerAUzA@mail.gmail.com>
Will,
On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote:
> On 13 July 2018 at 02:34, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote:
> >> Hi Akashi,
> >>
> >> On Tue, Jul 10, 2018 at 08:42:25AM +0900, AKASHI Takahiro wrote:
> >> > This patch series is a set of bug fixes to address kexec/kdump
> >> > failures which are sometimes observed on ACPI-only system and reported
> >> > in LAK-ML before.
> >>
> >> I tried picking this up, along with Ard's fixup, but I'm seeing a build
> >> failure for allmodconfig:
> >>
> >> arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
> >> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'
> >>
> >> I didn't investigate further. Please can you fix this?
> >
> > Because CONFIG_ACPI is on and CONFIG_EFI is off.
> >
> > This can happen in allmodconfig as CONFIG_EFI depends on
> > !CONFIG_CPU_BIG_ENDIAN, which is actually on in this case.
> >
>
> Allowing both CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN to be configured
> makes no sense at all. Things will surely break if you start using BE
> memory accesses while parsing ACPI tables.
>
> Allowing CONFIG_ACPI without CONFIG_EFI makes no sense either, since
> on arm64, the only way to find the ACPI tables is through a UEFI
> configuration table.
Do you agree to this?
-Takahiro AKASHI
> > Looking at __acpi_get_mem_attributes(), since there is no information
> > available on memory attributes, what we can do at best is
> > * return PAGE_KERNEL (= cacheable) for mapped memory,
> > * return DEVICE_nGnRnE (= non-cacheable) otherwise
> > (See a hunk to be applied on top of my patch#4.)
> >
> > I think that, after applying, acpi_os_ioremap() would work almost
> > in the same way as the original before my patchset given that
> > MAP memblock attribute is used only under CONFIG_EFI for now.
> >
> > Make sense?
> >
>
> Let's keep your code as is but fix the Kconfig dependencies instead.
WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
"Baicar, Tyler" <tbaicar@codeaurora.org>,
Bhupesh Sharma <bhsharma@redhat.com>,
Dave Young <dyoung@redhat.com>, James Morse <james.morse@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Al Stone <al.stone@linaro.org>,
Graeme Gregory <graeme.gregory@linaro.org>,
Hanjun Guo <hanjun.guo@linaro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system
Date: Tue, 17 Jul 2018 14:12:23 +0900 [thread overview]
Message-ID: <20180717051222.GA11258@linaro.org> (raw)
In-Reply-To: <CAKv+Gu9PT75XTXGsh1jc5roRO_d2QYKEamq42mfbsXzmerAUzA@mail.gmail.com>
Will,
On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote:
> On 13 July 2018 at 02:34, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote:
> >> Hi Akashi,
> >>
> >> On Tue, Jul 10, 2018 at 08:42:25AM +0900, AKASHI Takahiro wrote:
> >> > This patch series is a set of bug fixes to address kexec/kdump
> >> > failures which are sometimes observed on ACPI-only system and reported
> >> > in LAK-ML before.
> >>
> >> I tried picking this up, along with Ard's fixup, but I'm seeing a build
> >> failure for allmodconfig:
> >>
> >> arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
> >> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'
> >>
> >> I didn't investigate further. Please can you fix this?
> >
> > Because CONFIG_ACPI is on and CONFIG_EFI is off.
> >
> > This can happen in allmodconfig as CONFIG_EFI depends on
> > !CONFIG_CPU_BIG_ENDIAN, which is actually on in this case.
> >
>
> Allowing both CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN to be configured
> makes no sense at all. Things will surely break if you start using BE
> memory accesses while parsing ACPI tables.
>
> Allowing CONFIG_ACPI without CONFIG_EFI makes no sense either, since
> on arm64, the only way to find the ACPI tables is through a UEFI
> configuration table.
Do you agree to this?
-Takahiro AKASHI
> > Looking at __acpi_get_mem_attributes(), since there is no information
> > available on memory attributes, what we can do at best is
> > * return PAGE_KERNEL (= cacheable) for mapped memory,
> > * return DEVICE_nGnRnE (= non-cacheable) otherwise
> > (See a hunk to be applied on top of my patch#4.)
> >
> > I think that, after applying, acpi_os_ioremap() would work almost
> > in the same way as the original before my patchset given that
> > MAP memblock attribute is used only under CONFIG_EFI for now.
> >
> > Make sense?
> >
>
> Let's keep your code as is but fix the Kconfig dependencies instead.
next prev parent reply other threads:[~2018-07-17 5:11 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 23:42 [PATCH v3.1 0/4] arm64: kexec, kdump: fix boot failures on acpi-only system AKASHI Takahiro
2018-07-09 23:42 ` [PATCH v3.1 0/4] arm64: kexec,kdump: " AKASHI Takahiro
2018-07-09 23:42 ` [PATCH v3.1 0/4] arm64: kexec, kdump: " AKASHI Takahiro
2018-07-09 23:42 ` [PATCH v3.1 1/4] arm64: export memblock_reserve()d regions via /proc/iomem AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-09 23:42 ` [PATCH v3.1 2/4] efi/arm: preserve early mapping of UEFI memory map longer for BGRT AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-10 17:57 ` James Morse
2018-07-10 17:57 ` James Morse
2018-07-10 17:57 ` James Morse
2018-07-10 18:39 ` Ard Biesheuvel
2018-07-10 18:39 ` Ard Biesheuvel
2018-07-10 18:39 ` Ard Biesheuvel
2018-07-12 13:32 ` Will Deacon
2018-07-12 13:32 ` Will Deacon
2018-07-12 13:32 ` Will Deacon
2018-07-12 14:14 ` Ard Biesheuvel
2018-07-12 14:14 ` Ard Biesheuvel
2018-07-12 14:14 ` Ard Biesheuvel
2018-07-09 23:42 ` [PATCH v3.1 3/4] efi/arm: map UEFI memory map even w/o runtime services enabled AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-09 23:42 ` [PATCH v3.1 4/4] arm64: acpi: fix alignment fault in accessing ACPI AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-09 23:42 ` AKASHI Takahiro
2018-07-12 16:49 ` [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system Will Deacon
2018-07-12 16:49 ` Will Deacon
2018-07-12 16:49 ` Will Deacon
2018-07-13 0:34 ` AKASHI Takahiro
2018-07-13 0:34 ` AKASHI Takahiro
2018-07-13 0:34 ` AKASHI Takahiro
2018-07-13 5:49 ` Ard Biesheuvel
2018-07-13 5:49 ` Ard Biesheuvel
2018-07-13 5:49 ` Ard Biesheuvel
2018-07-17 5:12 ` AKASHI Takahiro [this message]
2018-07-17 5:12 ` AKASHI Takahiro
2018-07-17 5:12 ` AKASHI Takahiro
2018-07-23 13:35 ` Will Deacon
2018-07-23 13:35 ` Will Deacon
2018-07-23 13:35 ` Will Deacon
2018-07-24 5:19 ` Bhupesh Sharma
2018-07-24 5:19 ` Bhupesh Sharma
2018-07-24 5:19 ` Bhupesh Sharma
2018-07-12 21:47 ` [PATCH v3.1 0/4] arm64: kexec, kdump: " Richard Ruigrok
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=20180717051222.GA11258@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=al.stone@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bhsharma@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=graeme.gregory@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=james.morse@arm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=sudeep.holla@arm.com \
--cc=tbaicar@codeaurora.org \
--cc=will.deacon@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.