linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	dhowells@redhat.com, vgoyal@redhat.com,
	herbert@gondor.apana.org.au, davem@davemloft.net,
	dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com
Cc: prudo@linux.ibm.com, ard.biesheuvel@linaro.org,
	james.morse@arm.com, bhsharma@redhat.com,
	kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v14 06/16] of/fdt: add helper functions for handling properties
Date: Fri, 14 Sep 2018 10:19:38 -0700	[thread overview]
Message-ID: <16a39f7f-a8cc-72a1-89a7-e9b49a4d6547@gmail.com> (raw)
In-Reply-To: <8403dfd5-3188-219b-966c-72b009f94e0f@gmail.com>

On 09/13/18 18:26, Frank Rowand wrote:
> I was re-reading this while answering a later email in the thread.  After reading
> other patches in the series that were not sent to me, I have a better understanding
> of the intent behind this patch, and some changes to my previous reply.
> 
> The intent of the helper functions is related to properties whose values are
> tuples of the same format as the "reg" property of the "/memory" nodes.  For
> example, the "linux,usable-memory-range" and "linux,elfcoredhr" properties of
> the "/chosen" node.
> 
> The patch header and the function names should be updated to reflect this intent.
> This means most or all of my previous suggested function name changes are no longer
> useful.
> 
> Please add devicetree@vger.kernel.org to the next version of this patch and to
> the patches that use the functions in this patch.
> 
> 
> On 09/07/18 12:53, Frank Rowand wrote:
>> On 09/07/18 01:00, AKASHI Takahiro 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>
>>> ---
>>>  drivers/of/fdt.c       | 62 ++++++++++++++++++++++++++++++++++++++++--
>>>  include/linux/of_fdt.h | 10 +++++--
>>>  2 files changed, 68 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>> index 800ad252cf9c..dc960cea1355 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>
>>> @@ -537,8 +538,8 @@ void *of_fdt_unflatten_tree(const unsigned long *blob,
>>>  EXPORT_SYMBOL_GPL(of_fdt_unflatten_tree);
>>>  
>>>  /* Everything below here references initial_boot_params directly. */
>>> -int __initdata dt_root_addr_cells;
>>> -int __initdata dt_root_size_cells;
>>> +int dt_root_addr_cells;
>>> +int dt_root_size_cells;
>>>  
>>>  void *initial_boot_params;
>>>  
>>> @@ -1323,3 +1324,60 @@ late_initcall(of_fdt_raw_init);
>>>  #endif
>>>  
>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
>>> +
> 
> Global comment: this code should not be using the variables
> dt_root_addr_cells and dt_root_size_cells.  These variables are
> __initdata.
> 
> The code that is using these helpers is acting upon a specific FDT
> (copied from initial_boot_params).  This code should be getting the
> values of the root node's "#address-cells" and "#size-cells" from
> the FDT.

There will be new functions available soon to return the values of
a node's "#address-cells" and "#size-cells" from an fdt.  They are
fdt_address_cells() and fdt_size_cells().

Rob submitted the patch to add them yesterday in "[PATCH 3/3] scripts/dtc:
Update to upstream version v1.4.7-14-gc86da84d30e4" [1]

  [1] https://lkml.kernel.org/r/<20180913202828.15372-3-robh@kernel.org>

-Frank


> 
> 
>> Please add comment:
>>
>> /* helper functions for arm64 kexec */
>>
>>
>>> +bool of_fdt_cells_size_fitted(u64 base, u64 size)
>>
>> Please rename as of_fdt_range_valid()
> 
> I'm not entirely sure of what the caller in 12/16 is trying to ensure
> with this function.
> 
> (1) At the minimum (and what the implementation in of_fdt_cells_size_fitted()
> does) is make sure that an address and size tuple are consistent with
> the root properties "#address-cells" and "#size-cells".
> 
> The caller in 12/16 is using this check to validate values for the
> properties  "linux,elfcorehdr" and "linux,usable-memory-range".
> 
> (2) A more complete check _might_ be to ensure that the values also
> specify memory that is available to the kernel.  This memory is described
> by the "reg" property of one or more "/memory" nodes.
> 
> This second check is probably what is actually desired.
> 
> One possible issue to note is that the binding for "linux,usable-memory-range"
> suggests that available memory could be described by an EFI memory map.
> I am not familiar with how or when an EFI memory map might exist instead
> of the "/memory" nodes.
> 
> 
>>> +{
>>> +	/* if *_cells >= 2, cells can hold 64-bit values anyway */
>>> +	if ((dt_root_addr_cells == 1) && (base > U32_MAX))
>>> +		return false;
>>> +
>>> +	if ((dt_root_size_cells == 1) && (size > U32_MAX))
>>> +		return false;
>>
>> Should also check that base + size does not wrap around.
>>
>>
>>> +
>>> +	return true;
>>> +}
>>> +
>>> +size_t of_fdt_reg_cells_size(void)
>>
>> Please rename as of_fdt_root_range_size()
> 
> Even better would be to remove this function and replace the one place
> that it is called from with the one line of code in this function.
> 
> -Frank
> 
> 
>>> +{
>>> +	return (dt_root_addr_cells + dt_root_size_cells) * sizeof(u32);
>>> +}
>>> +
>>> +#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)
>>
>> Please rename as fdt_len_added_prop()
>>
>>
>>> +{
>>> +	return (strlen(prop_name) + 1) +
>>> +		sizeof(struct fdt_property) +
>>> +		FDT_TAGALIGN(len);
>>> +}
>>> +
>>
>> Please add comment, something like:
>>
>> /* cells must be 1 or 2 */
>>
>>
>>> +static void fill_property(void *buf, u64 val64, int cells)
>>
>> Please rename as cpu64_to_fdt_cells()
>>
>> Thanks,
>>
>> Frank
>>
>>> +{
>>> +	__be32 val32;
>>> +
>>> +	while (cells) {
>>> +		val32 = cpu_to_fdt32((val64 >> (32 * (--cells))) & U32_MAX);
>>> +		memcpy(buf, &val32, sizeof(val32));
>>> +		buf += sizeof(val32);
>>> +	}
>>> +}
>>> +
>>> +int fdt_setprop_reg(void *fdt, int nodeoffset, const char *name,
>>> +						u64 addr, u64 size)
>>> +{
>>> +	char buf[sizeof(__be32) * 2 * 2];
>>> +		/* assume dt_root_[addr|size]_cells <= 2 */
>>> +	void *prop;
>>> +	size_t buf_size;
>>> +
>>> +	buf_size = of_fdt_reg_cells_size();
>>> +	prop = buf;
>>> +
>>> +	fill_property(prop, addr, dt_root_addr_cells);
>>> +	prop += dt_root_addr_cells * sizeof(u32);
>>> +
>>> +	fill_property(prop, size, dt_root_size_cells);
>>> +
>>> +	return fdt_setprop(fdt, nodeoffset, name, buf, buf_size);
>>> +}
>>> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
>>> index b9cd9ebdf9b9..9615d6142578 100644
>>> --- a/include/linux/of_fdt.h
>>> +++ b/include/linux/of_fdt.h
>>> @@ -37,8 +37,8 @@ extern void *of_fdt_unflatten_tree(const unsigned long *blob,
>>>  				   struct device_node **mynodes);
>>>  
>>>  /* TBD: Temporary export of fdt globals - remove when code fully merged */
>>> -extern int __initdata dt_root_addr_cells;
>>> -extern int __initdata dt_root_size_cells;
>>> +extern int dt_root_addr_cells;
>>> +extern int dt_root_size_cells;
>>>  extern void *initial_boot_params;
>>>  
>>>  extern char __dtb_start[];
>>> @@ -108,5 +108,11 @@ static inline void unflatten_device_tree(void) {}
>>>  static inline void unflatten_and_copy_device_tree(void) {}
>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
>>>  
>>> +bool of_fdt_cells_size_fitted(u64 base, u64 size);
>>> +size_t of_fdt_reg_cells_size(void);
>>> +int fdt_prop_len(const char *prop_name, int len);
>>> +int fdt_setprop_reg(void *fdt, int nodeoffset, const char *name,
>>> +						u64 addr, u64 size);
>>> +
>>>  #endif /* __ASSEMBLY__ */
>>>  #endif /* _LINUX_OF_FDT_H */
>>>
>>
>>
> 
> 


  reply	other threads:[~2018-09-14 17:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07  8:00 [PATCH v14 06/16] of/fdt: add helper functions for handling properties AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 07/16] arm64: add image head flag definitions AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 08/16] arm64: cpufeature: add MMFR0 helper functions AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 09/16] arm64: enable KEXEC_FILE config AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 10/16] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 11/16] arm64: kexec_file: allow for loading Image-format kernel AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 12/16] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 13/16] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 14/16] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 15/16] arm64: kexec_file: add kernel signature verification support AKASHI Takahiro
2018-09-07  8:00 ` [PATCH v14 16/16] arm64: kexec_file: add kaslr support AKASHI Takahiro
2018-09-07 19:53 ` [PATCH v14 06/16] of/fdt: add helper functions for handling properties Frank Rowand
2018-09-10  2:38   ` AKASHI Takahiro
2018-09-14  1:42     ` Frank Rowand
2018-09-14  1:26   ` Frank Rowand
2018-09-14 17:19     ` Frank Rowand [this message]
2018-09-26  5:57       ` AKASHI Takahiro
2018-09-26  8:10         ` Frank Rowand

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=16a39f7f-a8cc-72a1-89a7-e9b49a4d6547@gmail.com \
    --to=frowand.list@gmail.com \
    --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=dhowells@redhat.com \
    --cc=dyoung@redhat.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=takahiro.akashi@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).