Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

[AKASHI Takahiro]

On Thu, May 18, 2017 at 01:59:14PM +0800, Dave Young wrote:
> Add Takahiro and Pratyush, they should be able to review the arm64 part.
> 
> On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> > This patch have minor updates in Documentation for arm64i as
> > relocatable kernel.
> > Also this patch updates documentation for using uncompressed
> > image "Image" which is used for ARM64.
> > 
> > Signed-off-by: Bharat Bhushan 
> > ---
> >  Documentation/kdump/kdump.txt | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> > index 615434d..522ce13 100644
> > --- a/Documentation/kdump/kdump.txt
> > +++ b/Documentation/kdump/kdump.txt
> > @@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
> >  2) Or use the system kernel binary itself as dump-capture kernel and there 
> > is
> > no need to build a separate dump-capture kernel. This is possible
> > only with the architectures which support a relocatable kernel. As
> > -   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
> > relocatable
> > -   kernel.
> > +   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
> > +   relocatable kernel.
> >  
> >  Building a relocatable kernel is advantageous from the point of view that
> >  one does not have to build a second kernel for capturing the dump. But
> > @@ -361,6 +361,12 @@ to load dump-capture kernel.
> > --dtb= \
> > --append="root= "
> >  
> > +If you are using a uncompressed Image, then use following command
> 
> s/a/an
> 
> > +to load dump-capture kernel.
> > +
> > +   kexec -p  \
> > +   --initrd= \
> > +   --append="root= "
> 
> For uncompressed Image, dtb is not necessary?

Just for clarification, dtb is optional for both vmlinux and Image
on arm64. (This means you can specify it if you want.)
But this is also true for initrd and append(command line) to some extent.

More precisely, whether these parameters are optional or not will
depend on architectures, not formats, I believe.

Thanks,
-Takahiro AKASHI

> >  
> >  Please note, that --args-linux does not need to be specified for ia64.
> >  It is planned to make this a no-op on that architecture, but for now
> > -- 
> > 1.9.3
> > 
> 
> Thanks
> Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

[AKASHI Takahiro]

On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote:
> Hi,
> 
> On 08/09/16 09:14, Arnd Bergmann wrote:
> > On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote:
> >> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote:
> >>> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote:
>  +   ctx->comm_base_addr = cppc_ss->base_address;
>  +   if (ctx->comm_base_addr) {
>  +   ctx->pcc_comm_addr =
>  +   
>  acpi_os_ioremap(ctx->comm_base_addr,
>  +   cppc_ss->length);
> 
> >>>
> >>> This causes the arm64 allmodconfig build to fail now, according to
> >>> kernelci:
> >>>
> >>>   1  ERROR: "memblock_is_memory" [drivers/hwmon/xgene-hwmon.ko] 
> >>> undefined!
> >>>
> >>> Should this perhaps call ioremap() or memremap() instead?
> >>>
> >> Hmmm ... almost sounds to me like blaming the messenger. e7cd190385d1 
> >> ("arm64:
> >> mark reserved memblock regions explicitly in iomem") starts using a 
> >> function
> >> in acpi_os_ioremap() which is not exported. On top of that, 
> >> memblock_is_memory()
> >> is declared as __init_memblock, which makes me really uncomfortable.
> >> If acpi_os_ioremap() must not be used by modules, and possibly only during
> >> early (?) initialization, maybe its declaration should state those 
> >> limitations ?
> > 
> > Ah, I didn't notice that. I guess both patches were correct individually and
> > got added to linux-next around the same time but caused allmodconfig to 
> > blow up
> > when used together.
> > 
> > Adding everyone who was involved in the memblock patch to Cc here, maybe one
> > of them has an idea what the correct fix is. There are only two other 
> > drivers
> > using acpi_os_ioremap() and one of them is x86-specific, so it's still 
> > likely
> > that drivers are not actually supposed to use this symbol. Making
> > acpi_os_ioremap() an exported function in arm64 would also work.
> 
> You could use acpi_os_map_iomem()/acpi_os_unmap_iomem() from acpi/acpi_io.h.
> If there isn't an existing mapping these end up in acpi_os_ioremap(), and are
> already EXPORT_SYMBOL_GPL().

acpi_os_ioremap() is re-defined in arm64/include/asm/acpi.h.

The problem is that, as memblock_is_memory() is declared as __init,
we cannot build any drivers which call acpi_os_ioremap() as modules.

As far as this specific issue is concerned, if we make a change like:

===8<===
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -207,7 +207,7 @@ static void __init request_standard_resources(void)
res = alloc_bootmem_low(sizeof(*res));
if (memblock_is_nomap(region)) {
res->name  = "reserved";
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
} else {
res->name  = "System RAM";
res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
===>8===

and revert the following hunk from the commit:

===8<===
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,7 +12,7 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
-#include 
+#include 
 #include 
 
 #include 
@@ -32,7 +32,11 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   if (!page_is_ram(phys >> PAGE_SHIFT))
+   /*
+* EFI's reserve_regions() call adds memory with the WB attribute
+* to memblock via early_init_dt_add_memory_arch().
+*/
+   if (!memblock_is_memory(phys))
return ioremap(phys, size);
 
return ioremap_cache(phys, size);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
===>8===

The build error will be gone. (and still kdump should work.)

But I don't know how we should distinguish IORESOURCE_MEM and
IORESOURCE_SYSTEM_RAM.

Thanks,
-Takahiro AKASHI

> (I'm still waiting for allmodconfig on linux-next to finish building)
> 
> 
> Thanks,
> 
> James
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html