All of lore.kernel.org
 help / color / mirror / Atom feed
From: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: prudo@linux.ibm.com, Herbert Xu <herbert@gondor.apana.org.au>,
	Baoquan He <bhe@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	bhsharma@redhat.com, Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	David Howells <dhowells@redhat.com>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	kexec@lists.infradead.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	James Morse <james.morse@arm.com>,
	dyoung@redhat.com, David Miller <davem@davemloft.net>,
	Vivek Goyal <vgoyal@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v15 06/16] of/fdt: add helper functions for handling properties
Date: Wed, 10 Oct 2018 10:14:28 +0900	[thread overview]
Message-ID: <20181010011426.GV32578@linaro.org> (raw)
In-Reply-To: <c65e42ce-1a98-7680-3a09-1f737eb26763@gmail.com>

Frank, Rob,

On Tue, Oct 09, 2018 at 10:47:15AM -0700, Frank Rowand wrote:
> On 10/08/18 17:37, AKASHI, Takahiro wrote:
> > On Fri, Oct 05, 2018 at 08:23:57AM -0500, Rob Herring wrote:
> >> On Thu, Oct 4, 2018 at 10:07 PM AKASHI, Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >>>
> >>> Rob,
> >>>
> >>> # I haven't replied to this comment yet.
> >>>
> >>> On Fri, Sep 28, 2018 at 08:44:42AM -0500, Rob Herring wrote:
> >>>> +David Gibson
> >>>>
> >>>> On Fri, Sep 28, 2018 at 1:48 AM AKASHI Takahiro
> >>>> <takahiro.akashi@linaro.org> wrote:
> >>>>>
> >>>>> These functions will be used later to handle kexec-specific properties
> >>>>> in arm64's kexec_file implementation.
> >>>>>
> >>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>> Cc: Frank Rowand <frowand.list@gmail.com>
> >>>>> Cc: devicetree@vger.kernel.org
> >>>>> ---
> >>>>>  drivers/of/fdt.c       | 56 ++++++++++++++++++++++++++++++++++++++++++
> >>>>>  include/linux/of_fdt.h |  4 +++
> >>>>>  2 files changed, 60 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> >>>>> index 800ad252cf9c..c65c31562ccb 100644
> >>>>> --- a/drivers/of/fdt.c
> >>>>> +++ b/drivers/of/fdt.c
> >>>>> @@ -25,6 +25,7 @@
> >>>>>  #include <linux/debugfs.h>
> >>>>>  #include <linux/serial_core.h>
> >>>>>  #include <linux/sysfs.h>
> >>>>> +#include <linux/types.h>
> >>>>>
> >>>>>  #include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
> >>>>>  #include <asm/page.h>
> >>>>> @@ -1323,3 +1324,58 @@ late_initcall(of_fdt_raw_init);
> >>>>>  #endif
> >>>>>
> >>>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
> >>>>> +
> >>>>> +#define FDT_ALIGN(x, a)        (((x) + (a) - 1) & ~((a) - 1))
> >>>>> +#define FDT_TAGALIGN(x)        (FDT_ALIGN((x), FDT_TAGSIZE))
> >>>>> +
> >>>>> +int fdt_prop_len(const char *prop_name, int len)
> >>>>> +{
> >>>>> +       return (strlen(prop_name) + 1) +
> >>>>> +               sizeof(struct fdt_property) +
> >>>>> +               FDT_TAGALIGN(len);
> >>>>
> >>>> Looks like you are using this to calculate how much space you need to
> >>>> allocate in addition to the current DTB for a couple of new or
> >>>> replaced properties. I'm not sure that this calculation is completely
> >>>> accurate. And it is strange there doesn't seem to be any libfdt
> >>>> function for this already. It would be simpler to just add some fixed
> >>>> additional amount.
> >>>>
> >>>> Maybe David G has comments on this?
> >>>>
> >>>>> +}
> >>>>> +
> >>>>
> >>>> The rest of this should go in drivers/of/fdt_address.c. Ultimately, it
> >>>> should go into libfdt, but I'm fine with having it in the kernel for
> >>>> now.
> >>>
> >>> I'd like to have this function in the kernel for now.
> >>>
> >>>>> +static void fill_property(void *buf, u64 val64, int cells)
> >>>>> +{
> >>>>> +       __be32 val32;
> >>>>> +
> >>>>> +       while (cells) {
> >>>>> +               val32 = cpu_to_fdt32((val64 >> (32 * (--cells))) & U32_MAX);
> >>>>> +               memcpy(buf, &val32, sizeof(val32));
> >>>>> +               buf += sizeof(val32);
> >>>>
> >>>> This is kind of hard to read. I would copy u-boot's fdt_pack_reg function.
> >>>
> >>> Are you sure?
> >>> I originally implemented this function in a similar way that fdt_pack_reg()
> >>> was, but, you suggested, in your past comment[1], that we'd be better to
> >>> have of_read_number()-like implementation.
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/579118.html
> >>
> >> Yeah, you're right. Plus, I'm not sure the u-boot one would work for
> >> unaligned accesses with armv5 and earlier h/w.
> >>
> >> My only comment then is I think you can drop the U32_MAX masking.
> > 
> > Okay, then I will leave this function, yet renaming it to
> > cpu64_to_fdt_cells() after Frank's comment.
> 
> I have second guessed myself and do not like the name I suggested
> because what the function really does is either cpu32 to be32 or
> cpu64 to be64.

Okay.

> I agree with Rob that readability is important here.  Instead of
> having a fill_property() function, how about having inline code,
> something like (untested even for thinkos):
> 
> 	prop = buf;
> 
> 	if (addr_cells == 1) {
> 		*(__be32 *)prop = cpu32_to_be32(addr);
> 		prop += 4;
> 	} else {
> 		*(__be64 *)prop = cpu64_to_be64(addr);
> 		prop += 8;
> 	}
> 
> 	if (size_cells == 1)
> 		*(__be32 *)prop = cpu32_to_be32(size);
> 	else
> 		*(__be64 *)prop = cpu64_to_be64(size);
> 
> You might want to also give Rob a chance to bike shed on this
> suggestion.

Basically, I don't care either way, but what Rob suggested
is that some architecture(s) might not handle correctly
unaligned memory access here.

I just want to stay tuned with Rob.

Thanks,
-Takahiro Akashi

> -Frank
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> >>
> >> Rob
> > 
> 

_______________________________________________
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 v15 06/16] of/fdt: add helper functions for handling properties
Date: Wed, 10 Oct 2018 10:14:28 +0900	[thread overview]
Message-ID: <20181010011426.GV32578@linaro.org> (raw)
In-Reply-To: <c65e42ce-1a98-7680-3a09-1f737eb26763@gmail.com>

Frank, Rob,

On Tue, Oct 09, 2018 at 10:47:15AM -0700, Frank Rowand wrote:
> On 10/08/18 17:37, AKASHI, Takahiro wrote:
> > On Fri, Oct 05, 2018 at 08:23:57AM -0500, Rob Herring wrote:
> >> On Thu, Oct 4, 2018 at 10:07 PM AKASHI, Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >>>
> >>> Rob,
> >>>
> >>> # I haven't replied to this comment yet.
> >>>
> >>> On Fri, Sep 28, 2018 at 08:44:42AM -0500, Rob Herring wrote:
> >>>> +David Gibson
> >>>>
> >>>> On Fri, Sep 28, 2018 at 1:48 AM AKASHI Takahiro
> >>>> <takahiro.akashi@linaro.org> wrote:
> >>>>>
> >>>>> These functions will be used later to handle kexec-specific properties
> >>>>> in arm64's kexec_file implementation.
> >>>>>
> >>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>> Cc: Frank Rowand <frowand.list@gmail.com>
> >>>>> Cc: devicetree at vger.kernel.org
> >>>>> ---
> >>>>>  drivers/of/fdt.c       | 56 ++++++++++++++++++++++++++++++++++++++++++
> >>>>>  include/linux/of_fdt.h |  4 +++
> >>>>>  2 files changed, 60 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> >>>>> index 800ad252cf9c..c65c31562ccb 100644
> >>>>> --- a/drivers/of/fdt.c
> >>>>> +++ b/drivers/of/fdt.c
> >>>>> @@ -25,6 +25,7 @@
> >>>>>  #include <linux/debugfs.h>
> >>>>>  #include <linux/serial_core.h>
> >>>>>  #include <linux/sysfs.h>
> >>>>> +#include <linux/types.h>
> >>>>>
> >>>>>  #include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
> >>>>>  #include <asm/page.h>
> >>>>> @@ -1323,3 +1324,58 @@ late_initcall(of_fdt_raw_init);
> >>>>>  #endif
> >>>>>
> >>>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
> >>>>> +
> >>>>> +#define FDT_ALIGN(x, a)        (((x) + (a) - 1) & ~((a) - 1))
> >>>>> +#define FDT_TAGALIGN(x)        (FDT_ALIGN((x), FDT_TAGSIZE))
> >>>>> +
> >>>>> +int fdt_prop_len(const char *prop_name, int len)
> >>>>> +{
> >>>>> +       return (strlen(prop_name) + 1) +
> >>>>> +               sizeof(struct fdt_property) +
> >>>>> +               FDT_TAGALIGN(len);
> >>>>
> >>>> Looks like you are using this to calculate how much space you need to
> >>>> allocate in addition to the current DTB for a couple of new or
> >>>> replaced properties. I'm not sure that this calculation is completely
> >>>> accurate. And it is strange there doesn't seem to be any libfdt
> >>>> function for this already. It would be simpler to just add some fixed
> >>>> additional amount.
> >>>>
> >>>> Maybe David G has comments on this?
> >>>>
> >>>>> +}
> >>>>> +
> >>>>
> >>>> The rest of this should go in drivers/of/fdt_address.c. Ultimately, it
> >>>> should go into libfdt, but I'm fine with having it in the kernel for
> >>>> now.
> >>>
> >>> I'd like to have this function in the kernel for now.
> >>>
> >>>>> +static void fill_property(void *buf, u64 val64, int cells)
> >>>>> +{
> >>>>> +       __be32 val32;
> >>>>> +
> >>>>> +       while (cells) {
> >>>>> +               val32 = cpu_to_fdt32((val64 >> (32 * (--cells))) & U32_MAX);
> >>>>> +               memcpy(buf, &val32, sizeof(val32));
> >>>>> +               buf += sizeof(val32);
> >>>>
> >>>> This is kind of hard to read. I would copy u-boot's fdt_pack_reg function.
> >>>
> >>> Are you sure?
> >>> I originally implemented this function in a similar way that fdt_pack_reg()
> >>> was, but, you suggested, in your past comment[1], that we'd be better to
> >>> have of_read_number()-like implementation.
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/579118.html
> >>
> >> Yeah, you're right. Plus, I'm not sure the u-boot one would work for
> >> unaligned accesses with armv5 and earlier h/w.
> >>
> >> My only comment then is I think you can drop the U32_MAX masking.
> > 
> > Okay, then I will leave this function, yet renaming it to
> > cpu64_to_fdt_cells() after Frank's comment.
> 
> I have second guessed myself and do not like the name I suggested
> because what the function really does is either cpu32 to be32 or
> cpu64 to be64.

Okay.

> I agree with Rob that readability is important here.  Instead of
> having a fill_property() function, how about having inline code,
> something like (untested even for thinkos):
> 
> 	prop = buf;
> 
> 	if (addr_cells == 1) {
> 		*(__be32 *)prop = cpu32_to_be32(addr);
> 		prop += 4;
> 	} else {
> 		*(__be64 *)prop = cpu64_to_be64(addr);
> 		prop += 8;
> 	}
> 
> 	if (size_cells == 1)
> 		*(__be32 *)prop = cpu32_to_be32(size);
> 	else
> 		*(__be64 *)prop = cpu64_to_be64(size);
> 
> You might want to also give Rob a chance to bike shed on this
> suggestion.

Basically, I don't care either way, but what Rob suggested
is that some architecture(s) might not handle correctly
unaligned memory access here.

I just want to stay tuned with Rob.

Thanks,
-Takahiro Akashi

> -Frank
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> >>
> >> Rob
> > 
> 

WARNING: multiple messages have this Message-ID (diff)
From: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	David Howells <dhowells@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	David Miller <davem@davemloft.net>,
	dyoung@redhat.com, Baoquan He <bhe@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	prudo@linux.ibm.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	James Morse <james.morse@arm.com>,
	bhsharma@redhat.com, kexec@lists.infradead.org,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger>
Subject: Re: [PATCH v15 06/16] of/fdt: add helper functions for handling properties
Date: Wed, 10 Oct 2018 10:14:28 +0900	[thread overview]
Message-ID: <20181010011426.GV32578@linaro.org> (raw)
In-Reply-To: <c65e42ce-1a98-7680-3a09-1f737eb26763@gmail.com>

Frank, Rob,

On Tue, Oct 09, 2018 at 10:47:15AM -0700, Frank Rowand wrote:
> On 10/08/18 17:37, AKASHI, Takahiro wrote:
> > On Fri, Oct 05, 2018 at 08:23:57AM -0500, Rob Herring wrote:
> >> On Thu, Oct 4, 2018 at 10:07 PM AKASHI, Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >>>
> >>> Rob,
> >>>
> >>> # I haven't replied to this comment yet.
> >>>
> >>> On Fri, Sep 28, 2018 at 08:44:42AM -0500, Rob Herring wrote:
> >>>> +David Gibson
> >>>>
> >>>> On Fri, Sep 28, 2018 at 1:48 AM AKASHI Takahiro
> >>>> <takahiro.akashi@linaro.org> wrote:
> >>>>>
> >>>>> These functions will be used later to handle kexec-specific properties
> >>>>> in arm64's kexec_file implementation.
> >>>>>
> >>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>> Cc: Frank Rowand <frowand.list@gmail.com>
> >>>>> Cc: devicetree@vger.kernel.org
> >>>>> ---
> >>>>>  drivers/of/fdt.c       | 56 ++++++++++++++++++++++++++++++++++++++++++
> >>>>>  include/linux/of_fdt.h |  4 +++
> >>>>>  2 files changed, 60 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> >>>>> index 800ad252cf9c..c65c31562ccb 100644
> >>>>> --- a/drivers/of/fdt.c
> >>>>> +++ b/drivers/of/fdt.c
> >>>>> @@ -25,6 +25,7 @@
> >>>>>  #include <linux/debugfs.h>
> >>>>>  #include <linux/serial_core.h>
> >>>>>  #include <linux/sysfs.h>
> >>>>> +#include <linux/types.h>
> >>>>>
> >>>>>  #include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
> >>>>>  #include <asm/page.h>
> >>>>> @@ -1323,3 +1324,58 @@ late_initcall(of_fdt_raw_init);
> >>>>>  #endif
> >>>>>
> >>>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
> >>>>> +
> >>>>> +#define FDT_ALIGN(x, a)        (((x) + (a) - 1) & ~((a) - 1))
> >>>>> +#define FDT_TAGALIGN(x)        (FDT_ALIGN((x), FDT_TAGSIZE))
> >>>>> +
> >>>>> +int fdt_prop_len(const char *prop_name, int len)
> >>>>> +{
> >>>>> +       return (strlen(prop_name) + 1) +
> >>>>> +               sizeof(struct fdt_property) +
> >>>>> +               FDT_TAGALIGN(len);
> >>>>
> >>>> Looks like you are using this to calculate how much space you need to
> >>>> allocate in addition to the current DTB for a couple of new or
> >>>> replaced properties. I'm not sure that this calculation is completely
> >>>> accurate. And it is strange there doesn't seem to be any libfdt
> >>>> function for this already. It would be simpler to just add some fixed
> >>>> additional amount.
> >>>>
> >>>> Maybe David G has comments on this?
> >>>>
> >>>>> +}
> >>>>> +
> >>>>
> >>>> The rest of this should go in drivers/of/fdt_address.c. Ultimately, it
> >>>> should go into libfdt, but I'm fine with having it in the kernel for
> >>>> now.
> >>>
> >>> I'd like to have this function in the kernel for now.
> >>>
> >>>>> +static void fill_property(void *buf, u64 val64, int cells)
> >>>>> +{
> >>>>> +       __be32 val32;
> >>>>> +
> >>>>> +       while (cells) {
> >>>>> +               val32 = cpu_to_fdt32((val64 >> (32 * (--cells))) & U32_MAX);
> >>>>> +               memcpy(buf, &val32, sizeof(val32));
> >>>>> +               buf += sizeof(val32);
> >>>>
> >>>> This is kind of hard to read. I would copy u-boot's fdt_pack_reg function.
> >>>
> >>> Are you sure?
> >>> I originally implemented this function in a similar way that fdt_pack_reg()
> >>> was, but, you suggested, in your past comment[1], that we'd be better to
> >>> have of_read_number()-like implementation.
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/579118.html
> >>
> >> Yeah, you're right. Plus, I'm not sure the u-boot one would work for
> >> unaligned accesses with armv5 and earlier h/w.
> >>
> >> My only comment then is I think you can drop the U32_MAX masking.
> > 
> > Okay, then I will leave this function, yet renaming it to
> > cpu64_to_fdt_cells() after Frank's comment.
> 
> I have second guessed myself and do not like the name I suggested
> because what the function really does is either cpu32 to be32 or
> cpu64 to be64.

Okay.

> I agree with Rob that readability is important here.  Instead of
> having a fill_property() function, how about having inline code,
> something like (untested even for thinkos):
> 
> 	prop = buf;
> 
> 	if (addr_cells == 1) {
> 		*(__be32 *)prop = cpu32_to_be32(addr);
> 		prop += 4;
> 	} else {
> 		*(__be64 *)prop = cpu64_to_be64(addr);
> 		prop += 8;
> 	}
> 
> 	if (size_cells == 1)
> 		*(__be32 *)prop = cpu32_to_be32(size);
> 	else
> 		*(__be64 *)prop = cpu64_to_be64(size);
> 
> You might want to also give Rob a chance to bike shed on this
> suggestion.

Basically, I don't care either way, but what Rob suggested
is that some architecture(s) might not handle correctly
unaligned memory access here.

I just want to stay tuned with Rob.

Thanks,
-Takahiro Akashi

> -Frank
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> >>
> >> Rob
> > 
> 

WARNING: multiple messages have this Message-ID (diff)
From: "AKASHI, Takahiro" <takahiro.akashi@linaro.org>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	David Howells <dhowells@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	David Miller <davem@davemloft.net>,
	dyoung@redhat.com, Baoquan He <bhe@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	prudo@linux.ibm.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	James Morse <james.morse@arm.com>,
	bhsharma@redhat.com, kexec@lists.infradead.org,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v15 06/16] of/fdt: add helper functions for handling properties
Date: Wed, 10 Oct 2018 10:14:28 +0900	[thread overview]
Message-ID: <20181010011426.GV32578@linaro.org> (raw)
In-Reply-To: <c65e42ce-1a98-7680-3a09-1f737eb26763@gmail.com>

Frank, Rob,

On Tue, Oct 09, 2018 at 10:47:15AM -0700, Frank Rowand wrote:
> On 10/08/18 17:37, AKASHI, Takahiro wrote:
> > On Fri, Oct 05, 2018 at 08:23:57AM -0500, Rob Herring wrote:
> >> On Thu, Oct 4, 2018 at 10:07 PM AKASHI, Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >>>
> >>> Rob,
> >>>
> >>> # I haven't replied to this comment yet.
> >>>
> >>> On Fri, Sep 28, 2018 at 08:44:42AM -0500, Rob Herring wrote:
> >>>> +David Gibson
> >>>>
> >>>> On Fri, Sep 28, 2018 at 1:48 AM AKASHI Takahiro
> >>>> <takahiro.akashi@linaro.org> wrote:
> >>>>>
> >>>>> These functions will be used later to handle kexec-specific properties
> >>>>> in arm64's kexec_file implementation.
> >>>>>
> >>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>> Cc: Frank Rowand <frowand.list@gmail.com>
> >>>>> Cc: devicetree@vger.kernel.org
> >>>>> ---
> >>>>>  drivers/of/fdt.c       | 56 ++++++++++++++++++++++++++++++++++++++++++
> >>>>>  include/linux/of_fdt.h |  4 +++
> >>>>>  2 files changed, 60 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> >>>>> index 800ad252cf9c..c65c31562ccb 100644
> >>>>> --- a/drivers/of/fdt.c
> >>>>> +++ b/drivers/of/fdt.c
> >>>>> @@ -25,6 +25,7 @@
> >>>>>  #include <linux/debugfs.h>
> >>>>>  #include <linux/serial_core.h>
> >>>>>  #include <linux/sysfs.h>
> >>>>> +#include <linux/types.h>
> >>>>>
> >>>>>  #include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
> >>>>>  #include <asm/page.h>
> >>>>> @@ -1323,3 +1324,58 @@ late_initcall(of_fdt_raw_init);
> >>>>>  #endif
> >>>>>
> >>>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
> >>>>> +
> >>>>> +#define FDT_ALIGN(x, a)        (((x) + (a) - 1) & ~((a) - 1))
> >>>>> +#define FDT_TAGALIGN(x)        (FDT_ALIGN((x), FDT_TAGSIZE))
> >>>>> +
> >>>>> +int fdt_prop_len(const char *prop_name, int len)
> >>>>> +{
> >>>>> +       return (strlen(prop_name) + 1) +
> >>>>> +               sizeof(struct fdt_property) +
> >>>>> +               FDT_TAGALIGN(len);
> >>>>
> >>>> Looks like you are using this to calculate how much space you need to
> >>>> allocate in addition to the current DTB for a couple of new or
> >>>> replaced properties. I'm not sure that this calculation is completely
> >>>> accurate. And it is strange there doesn't seem to be any libfdt
> >>>> function for this already. It would be simpler to just add some fixed
> >>>> additional amount.
> >>>>
> >>>> Maybe David G has comments on this?
> >>>>
> >>>>> +}
> >>>>> +
> >>>>
> >>>> The rest of this should go in drivers/of/fdt_address.c. Ultimately, it
> >>>> should go into libfdt, but I'm fine with having it in the kernel for
> >>>> now.
> >>>
> >>> I'd like to have this function in the kernel for now.
> >>>
> >>>>> +static void fill_property(void *buf, u64 val64, int cells)
> >>>>> +{
> >>>>> +       __be32 val32;
> >>>>> +
> >>>>> +       while (cells) {
> >>>>> +               val32 = cpu_to_fdt32((val64 >> (32 * (--cells))) & U32_MAX);
> >>>>> +               memcpy(buf, &val32, sizeof(val32));
> >>>>> +               buf += sizeof(val32);
> >>>>
> >>>> This is kind of hard to read. I would copy u-boot's fdt_pack_reg function.
> >>>
> >>> Are you sure?
> >>> I originally implemented this function in a similar way that fdt_pack_reg()
> >>> was, but, you suggested, in your past comment[1], that we'd be better to
> >>> have of_read_number()-like implementation.
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/579118.html
> >>
> >> Yeah, you're right. Plus, I'm not sure the u-boot one would work for
> >> unaligned accesses with armv5 and earlier h/w.
> >>
> >> My only comment then is I think you can drop the U32_MAX masking.
> > 
> > Okay, then I will leave this function, yet renaming it to
> > cpu64_to_fdt_cells() after Frank's comment.
> 
> I have second guessed myself and do not like the name I suggested
> because what the function really does is either cpu32 to be32 or
> cpu64 to be64.

Okay.

> I agree with Rob that readability is important here.  Instead of
> having a fill_property() function, how about having inline code,
> something like (untested even for thinkos):
> 
> 	prop = buf;
> 
> 	if (addr_cells == 1) {
> 		*(__be32 *)prop = cpu32_to_be32(addr);
> 		prop += 4;
> 	} else {
> 		*(__be64 *)prop = cpu64_to_be64(addr);
> 		prop += 8;
> 	}
> 
> 	if (size_cells == 1)
> 		*(__be32 *)prop = cpu32_to_be32(size);
> 	else
> 		*(__be64 *)prop = cpu64_to_be64(size);
> 
> You might want to also give Rob a chance to bike shed on this
> suggestion.

Basically, I don't care either way, but what Rob suggested
is that some architecture(s) might not handle correctly
unaligned memory access here.

I just want to stay tuned with Rob.

Thanks,
-Takahiro Akashi

> -Frank
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> >>
> >> Rob
> > 
> 

  reply	other threads:[~2018-10-10  1:13 UTC|newest]

Thread overview: 138+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28  6:48 [PATCH v15 00/16] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-09-28  6:48 ` AKASHI Takahiro
2018-09-28  6:48 ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 01/16] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 02/16] kexec_file: make kexec_image_post_load_cleanup_default() global AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 03/16] s390, kexec_file: drop arch_kexec_mem_walk() AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 04/16] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem() AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-30 10:08   ` Dave Young
2018-09-30 10:08     ` Dave Young
2018-09-30 10:08     ` Dave Young
2018-10-02  6:20     ` AKASHI Takahiro
2018-10-02  6:20       ` AKASHI Takahiro
2018-10-02  6:20       ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 05/16] kexec_file: kexec_walk_memblock() only walks a dedicated region at kdump AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-30 10:10   ` Dave Young
2018-09-30 10:10     ` Dave Young
2018-09-30 10:10     ` Dave Young
2018-09-28  6:48 ` [PATCH v15 06/16] of/fdt: add helper functions for handling properties AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  9:04   ` kbuild test robot
2018-09-28  9:04     ` kbuild test robot
2018-09-28  9:04     ` kbuild test robot
2018-09-28  9:04     ` kbuild test robot
2018-09-28 13:44   ` Rob Herring
2018-09-28 13:44     ` Rob Herring
2018-09-28 13:44     ` Rob Herring
2018-09-28 13:44     ` Rob Herring
2018-09-28 21:13     ` Frank Rowand
2018-09-28 21:13       ` Frank Rowand
2018-09-28 21:13       ` Frank Rowand
2018-10-05  5:06       ` AKASHI, Takahiro
2018-10-05  5:06         ` AKASHI, Takahiro
2018-10-05  5:06         ` AKASHI, Takahiro
2018-10-05  5:06         ` AKASHI, Takahiro
2018-10-05  5:09         ` David Gibson
2018-10-05  5:09           ` David Gibson
2018-10-05  5:09           ` David Gibson
2018-10-09 18:02         ` Frank Rowand
2018-10-09 18:02           ` Frank Rowand
2018-10-09 18:02           ` Frank Rowand
2018-10-10  0:30           ` David Gibson
2018-10-10  0:30             ` David Gibson
2018-10-10  0:30             ` David Gibson
2018-10-10  0:30             ` David Gibson
2018-10-10  1:04           ` AKASHI, Takahiro
2018-10-10  1:04             ` AKASHI, Takahiro
2018-10-10  1:04             ` AKASHI, Takahiro
2018-10-10  1:04             ` AKASHI, Takahiro
2018-10-02  4:47     ` David Gibson
2018-10-02  4:47       ` David Gibson
2018-10-02  4:47       ` David Gibson
2018-10-02  4:47       ` David Gibson
2018-10-02  9:04       ` AKASHI, Takahiro
2018-10-02  9:04         ` AKASHI, Takahiro
2018-10-02  9:04         ` AKASHI, Takahiro
2018-10-02  9:04         ` AKASHI, Takahiro
2018-10-05  3:08     ` AKASHI, Takahiro
2018-10-05  3:08       ` AKASHI, Takahiro
2018-10-05  3:08       ` AKASHI, Takahiro
2018-10-05 13:23       ` Rob Herring
2018-10-05 13:23         ` Rob Herring
2018-10-05 13:23         ` Rob Herring
2018-10-09  0:37         ` AKASHI, Takahiro
2018-10-09  0:37           ` AKASHI, Takahiro
2018-10-09  0:37           ` AKASHI, Takahiro
2018-10-09  0:37           ` AKASHI, Takahiro
2018-10-09 17:47           ` Frank Rowand
2018-10-09 17:47             ` Frank Rowand
2018-10-09 17:47             ` Frank Rowand
2018-10-10  1:14             ` AKASHI, Takahiro [this message]
2018-10-10  1:14               ` AKASHI, Takahiro
2018-10-10  1:14               ` AKASHI, Takahiro
2018-10-10  1:14               ` AKASHI, Takahiro
2018-10-10  2:44               ` Frank Rowand
2018-10-10  2:44                 ` Frank Rowand
2018-10-10  2:44                 ` Frank Rowand
2018-09-28  6:48 ` [PATCH v15 07/16] arm64: add image head flag definitions AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-10-01 12:52   ` Mark Rutland
2018-10-01 12:52     ` Mark Rutland
2018-10-01 12:52     ` Mark Rutland
2018-10-02  7:59     ` AKASHI Takahiro
2018-10-02  7:59       ` AKASHI Takahiro
2018-10-02  7:59       ` AKASHI Takahiro
2018-10-09 15:04       ` Mark Rutland
2018-10-09 15:04         ` Mark Rutland
2018-10-09 15:04         ` Mark Rutland
2018-10-10  1:59         ` AKASHI Takahiro
2018-10-10  1:59           ` AKASHI Takahiro
2018-10-10  1:59           ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 08/16] arm64: cpufeature: add MMFR0 helper functions AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 09/16] arm64: enable KEXEC_FILE config AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 10/16] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 11/16] arm64: kexec_file: allow for loading Image-format kernel AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-10-09 15:28   ` Mark Rutland
2018-10-09 15:28     ` Mark Rutland
2018-10-09 15:28     ` Mark Rutland
2018-10-10  6:52     ` AKASHI Takahiro
2018-10-10  6:52       ` AKASHI Takahiro
2018-10-10  6:52       ` AKASHI Takahiro
2018-10-10  9:47       ` Mark Rutland
2018-10-10  9:47         ` Mark Rutland
2018-10-10  9:47         ` Mark Rutland
2018-09-28  6:48 ` [PATCH v15 12/16] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 13/16] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 14/16] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 15/16] arm64: kexec_file: add kernel signature verification support AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48 ` [PATCH v15 16/16] arm64: kexec_file: add kaslr support AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro
2018-09-28  6:48   ` AKASHI Takahiro

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=20181010011426.GV32578@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=frowand.list@gmail.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prudo@linux.ibm.com \
    --cc=robh+dt@kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=vgoyal@redhat.com \
    --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.