All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	James Morse <james.morse@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Baicar, Tyler" <tbaicar@codeaurora.org>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	Dave Young <dyoung@redhat.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 v2 3/4] efi/arm: map UEFI memory map earlier on boot
Date: Fri, 6 Jul 2018 14:37:59 +0100	[thread overview]
Message-ID: <20180706133758.GB11172@arm.com> (raw)
In-Reply-To: <20180706013311.GP28220@linaro.org>

Hi Akashi,

On Fri, Jul 06, 2018 at 10:33:13AM +0900, AKASHI Takahiro wrote:
> On Fri, Jul 06, 2018 at 09:42:28AM +0900, AKASHI Takahiro wrote:
> > I almost believed that my patch#2 was just a preparatory one for patch#3
> > where arm_enable_runtime_services() is moved aggressively forward.
> > But acpi_os_ioremap() is not a __init function and I can now agree to
> > keeping patch#2.
> > 
> > Meanwhile, the consequent code with Ard's patch would look like:
> > ---8<---
> > static int __init arm_enable_runtime_services(void)
> > {
> >         ...
> >         efi_memmap_unmap();
> > 
> >         mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
> > 
> >         if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
> >                 pr_err("Failed to remap EFI memory map\n");
> >                 return 0;
> >         }
> >         ...
> > }
> > --->8---
> > It seems to me that it makes no sense.
> 
> Oops, it does. Comments at efi_memmap_init_late() say:
> ---8<---
>  * The reason there are two EFI memmap initialisation
>  * (efi_memmap_init_early() and this late version) is because the
>  * early EFI memmap should be explicitly unmapped once EFI
>  * initialisation is complete as the fixmap space used to map the EFI
>  * memmap (via early_memremap()) is a scarce resource.
> --->8---
> 
> > Is it okay to take them out?
> 
> Never mind.

I'm struggling with your monologue...

Please can you send a v3 of the series, containing the patches that you
think are necessary, along with the Acks you've collected?

Thanks,

Will

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot
Date: Fri, 6 Jul 2018 14:37:59 +0100	[thread overview]
Message-ID: <20180706133758.GB11172@arm.com> (raw)
In-Reply-To: <20180706013311.GP28220@linaro.org>

Hi Akashi,

On Fri, Jul 06, 2018 at 10:33:13AM +0900, AKASHI Takahiro wrote:
> On Fri, Jul 06, 2018 at 09:42:28AM +0900, AKASHI Takahiro wrote:
> > I almost believed that my patch#2 was just a preparatory one for patch#3
> > where arm_enable_runtime_services() is moved aggressively forward.
> > But acpi_os_ioremap() is not a __init function and I can now agree to
> > keeping patch#2.
> > 
> > Meanwhile, the consequent code with Ard's patch would look like:
> > ---8<---
> > static int __init arm_enable_runtime_services(void)
> > {
> >         ...
> >         efi_memmap_unmap();
> > 
> >         mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
> > 
> >         if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
> >                 pr_err("Failed to remap EFI memory map\n");
> >                 return 0;
> >         }
> >         ...
> > }
> > --->8---
> > It seems to me that it makes no sense.
> 
> Oops, it does. Comments at efi_memmap_init_late() say:
> ---8<---
>  * The reason there are two EFI memmap initialisation
>  * (efi_memmap_init_early() and this late version) is because the
>  * early EFI memmap should be explicitly unmapped once EFI
>  * initialisation is complete as the fixmap space used to map the EFI
>  * memmap (via early_memremap()) is a scarce resource.
> --->8---
> 
> > Is it okay to take them out?
> 
> Never mind.

I'm struggling with your monologue...

Please can you send a v3 of the series, containing the patches that you
think are necessary, along with the Acks you've collected?

Thanks,

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	James Morse <james.morse@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Baicar, Tyler" <tbaicar@codeaurora.org>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	Dave Young <dyoung@redhat.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 v2 3/4] efi/arm: map UEFI memory map earlier on boot
Date: Fri, 6 Jul 2018 14:37:59 +0100	[thread overview]
Message-ID: <20180706133758.GB11172@arm.com> (raw)
In-Reply-To: <20180706013311.GP28220@linaro.org>

Hi Akashi,

On Fri, Jul 06, 2018 at 10:33:13AM +0900, AKASHI Takahiro wrote:
> On Fri, Jul 06, 2018 at 09:42:28AM +0900, AKASHI Takahiro wrote:
> > I almost believed that my patch#2 was just a preparatory one for patch#3
> > where arm_enable_runtime_services() is moved aggressively forward.
> > But acpi_os_ioremap() is not a __init function and I can now agree to
> > keeping patch#2.
> > 
> > Meanwhile, the consequent code with Ard's patch would look like:
> > ---8<---
> > static int __init arm_enable_runtime_services(void)
> > {
> >         ...
> >         efi_memmap_unmap();
> > 
> >         mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
> > 
> >         if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
> >                 pr_err("Failed to remap EFI memory map\n");
> >                 return 0;
> >         }
> >         ...
> > }
> > --->8---
> > It seems to me that it makes no sense.
> 
> Oops, it does. Comments at efi_memmap_init_late() say:
> ---8<---
>  * The reason there are two EFI memmap initialisation
>  * (efi_memmap_init_early() and this late version) is because the
>  * early EFI memmap should be explicitly unmapped once EFI
>  * initialisation is complete as the fixmap space used to map the EFI
>  * memmap (via early_memremap()) is a scarce resource.
> --->8---
> 
> > Is it okay to take them out?
> 
> Never mind.

I'm struggling with your monologue...

Please can you send a v3 of the series, containing the patches that you
think are necessary, along with the Acks you've collected?

Thanks,

Will

  reply	other threads:[~2018-07-06 13:37 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19  6:44 [PATCH v2 0/4] arm64: kexec, kdump: fix boot failures on acpi-only system AKASHI Takahiro
2018-06-19  6:44 ` [PATCH v2 0/4] arm64: kexec,kdump: " AKASHI Takahiro
2018-06-19  6:44 ` [PATCH v2 0/4] arm64: kexec, kdump: " AKASHI Takahiro
2018-06-19  6:44 ` [PATCH v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-19 13:37   ` Dave Kleikamp
2018-06-19 13:37     ` Dave Kleikamp
2018-06-19 13:37     ` Dave Kleikamp
2018-06-19 15:00     ` James Morse
2018-06-19 15:00       ` James Morse
2018-06-19 15:00       ` James Morse
2018-06-19 15:22       ` Dave Kleikamp
2018-06-19 15:22         ` Dave Kleikamp
2018-06-19 15:22         ` Dave Kleikamp
2018-07-03  6:47         ` AKASHI Takahiro
2018-07-03  6:47           ` AKASHI Takahiro
2018-07-03  6:47           ` AKASHI Takahiro
2018-07-03 12:14           ` Bhupesh Sharma
2018-07-03 12:14             ` Bhupesh Sharma
2018-07-03 12:14             ` Bhupesh Sharma
2018-07-03 16:12           ` Dave Kleikamp
2018-07-03 16:12             ` Dave Kleikamp
2018-07-03 16:12             ` Dave Kleikamp
2018-07-05 22:29   ` Ard Biesheuvel
2018-07-05 22:29     ` Ard Biesheuvel
2018-07-05 22:29     ` Ard Biesheuvel
2018-06-19  6:44 ` [PATCH v2 2/4] efi/arm: map UEFI memory map even w/o runtime services enabled AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-28 17:29   ` James Morse
2018-06-28 17:29     ` James Morse
2018-06-28 17:29     ` James Morse
2018-07-05 22:26   ` Ard Biesheuvel
2018-07-05 22:26     ` Ard Biesheuvel
2018-07-05 22:26     ` Ard Biesheuvel
2018-06-19  6:44 ` [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-07-04 17:06   ` Will Deacon
2018-07-04 17:06     ` Will Deacon
2018-07-04 17:06     ` Will Deacon
2018-07-04 18:49     ` Ard Biesheuvel
2018-07-04 18:49       ` Ard Biesheuvel
2018-07-04 18:49       ` Ard Biesheuvel
2018-07-05  9:43       ` AKASHI Takahiro
2018-07-05  9:43         ` AKASHI Takahiro
2018-07-05  9:43         ` AKASHI Takahiro
2018-07-05 11:02         ` James Morse
2018-07-05 11:02           ` James Morse
2018-07-05 11:02           ` James Morse
2018-07-05 16:48           ` Will Deacon
2018-07-05 16:48             ` Will Deacon
2018-07-05 16:48             ` Will Deacon
2018-07-05 22:31             ` Ard Biesheuvel
2018-07-05 22:31               ` Ard Biesheuvel
2018-07-05 22:31               ` Ard Biesheuvel
2018-07-06  0:42               ` AKASHI Takahiro
2018-07-06  0:42                 ` AKASHI Takahiro
2018-07-06  0:42                 ` AKASHI Takahiro
2018-07-06  1:33                 ` AKASHI Takahiro
2018-07-06  1:33                   ` AKASHI Takahiro
2018-07-06  1:33                   ` AKASHI Takahiro
2018-07-06 13:37                   ` Will Deacon [this message]
2018-07-06 13:37                     ` Will Deacon
2018-07-06 13:37                     ` Will Deacon
2018-06-19  6:44 ` [PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-19  6:44   ` AKASHI Takahiro
2018-06-28 17:28   ` James Morse
2018-06-28 17:28     ` James Morse
2018-06-28 17:28     ` James Morse
2018-07-05 22:27   ` Ard Biesheuvel
2018-07-05 22:27     ` Ard Biesheuvel
2018-07-05 22:27     ` Ard Biesheuvel

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=20180706133758.GB11172@arm.com \
    --to=will.deacon@arm.com \
    --cc=akpm@linux-foundation.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=takahiro.akashi@linaro.org \
    --cc=tbaicar@codeaurora.org \
    /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.