Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp5174955imm; Tue, 9 Oct 2018 10:48:00 -0700 (PDT) X-Google-Smtp-Source: ACcGV60fHZ3hFI0QZHG5zjHULLiE/IR2Hp98b6MVmEzo588R1kBEW3kcSLhcDVJcpxrRz3/Q5nIG X-Received: by 2002:a63:e04d:: with SMTP id n13-v6mr26970423pgj.426.1539107280859; Tue, 09 Oct 2018 10:48:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539107280; cv=none; d=google.com; s=arc-20160816; b=SIOVH9hFPtRZUUdkSlnXrQnUVA7/VzLe+HPH6pNuVKWLVFJK82PEZH3LINx57OhVRK fk45EqgTSct/aNPC6X8n35yZws7/JZ+XA2Du16ZeIrg1cKchkj+7ucYMpQ+MuOGf7Xlc W1/QZp+knjSY0hK4j+enYHTjViV+nxxskZboj8go6BjkjxQmpX5su8Ipixp7CjhppiNg ovGsw9r+WITYOd7kcD0RYGst6+eXexTqDt3zyFS5rmu1BxH1kGJyxo2bycvfkbhKhzeO dXAq8CSI1EZXTKJ+89WbQXwvrxBZHvY0yGP03rh4NJPQiP8OV1CeG7ut1fzrBceCsW4x bf7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:dkim-signature; bh=NFWjmn9TDBkATQaXA+17wcOB9zqUAyWN/ATkHmUsFrI=; b=oz9czFfDyOHCXWmYg3n14ZVl/EoqCqk34cXvaBdujvhZgT44kuI2IggWWZxARX/IyG +Zw0hg6sx/wsMOasvdEPbTEw0JVzyoFDEHOj+o7lB5kR6XHm9GGOCjx/06MZILpG2gMJ jL57WwxTDBTfDTVgpzoepzE59jPnU7qsYLmLOeyIfZ3N7ndWTkI5nDprhd/j/V3vAS01 0uRzwRFoU9HLSZnZzGK3RO3lB7ezechpR502qQJKHAJQLKogG7/lb2SQW38HC4ajRoDx iP67InhtKcAtOm9iIP4WhUZNGsVQ1xJk9PMOxH+IWEY8AXDYc1OcaAnGiCoiFV7GHFj7 8JiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Wtf3xh+9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a7-v6si20909736pgb.301.2018.10.09.10.47.46; Tue, 09 Oct 2018 10:48:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Wtf3xh+9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726846AbeJJBF0 (ORCPT + 99 others); Tue, 9 Oct 2018 21:05:26 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:41984 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726415AbeJJBF0 (ORCPT ); Tue, 9 Oct 2018 21:05:26 -0400 Received: by mail-pl1-f193.google.com with SMTP id c8-v6so1181047plo.9; Tue, 09 Oct 2018 10:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=NFWjmn9TDBkATQaXA+17wcOB9zqUAyWN/ATkHmUsFrI=; b=Wtf3xh+91coxGwz0/GhW5Al1NovWJuWT8wWlaORqbX6i0cwDicJK/YSWNf6qKGcGuZ GEf9dmIRBwb+HuuES1bx2foO/tJRsY4uwnhdNpISaQAoSSVMhIP3OhKttBmL7bhI1Tgs JJgLY36EU6zUM2iwn7pFrwMHJQE6sJYpKoy3RgTEZgEoH+MA/T7VLb3K0jxoGJaK65rQ Xkbg+p/0hNIZ3uTcWSjkhZ574Gj60Ph9fUX/GY1lKMj+EzE66ZwwCnJGMGjl+o7BbbC4 oLCAJLpoYkgdHjdeRYR6A5IqAJH8brj7/PATaYc8F1CfeZYGivqX8hCUoJbelI8lknRI QYNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NFWjmn9TDBkATQaXA+17wcOB9zqUAyWN/ATkHmUsFrI=; b=V51BGKinGzovTSLSFBzn0rtbCINGVkuI1Ir9IFhcZfpGZJVyhpK6HMXSVuAQ95KpqR CBPa/p9j+WRkTNPtQEkDYarthSTTJKXx/6z04KfG8qhvRcS2co5qm+SguoIMSF0Ae003 20KIwGPEl1vVKJPRDXa5AOu+Bbxdz4IwQBs1nuFc+8i5iR25XzarwORAMSseia+fs39R w1EEmOLGiXf/c3A00RLJcz4guaED2AzBH9W+u6xZQdMvqTWcZyx6WFe14mAILX/2iu1w PzVvkBqURcYXjaIwfohcNjDQRbIY3Nx6pfSoVyifXlnqWEsceSWaeYWKj/07ThY6HnfB 1i0g== X-Gm-Message-State: ABuFfogxlht6zSdoNnLB8MOPTwpYfVGNvSbSbmj/DFvhrsCiJRW4FLuZ QtRQxSHhS4pkxvMpzqpeZoOPSm5P X-Received: by 2002:a17:902:be11:: with SMTP id r17-v6mr10028510pls.112.1539107239225; Tue, 09 Oct 2018 10:47:19 -0700 (PDT) Received: from [192.168.1.70] (c-24-6-192-50.hsd1.ca.comcast.net. [24.6.192.50]) by smtp.gmail.com with ESMTPSA id 22-v6sm29767184pfl.126.2018.10.09.10.47.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Oct 2018 10:47:18 -0700 (PDT) Subject: Re: [PATCH v15 06/16] of/fdt: add helper functions for handling properties To: "AKASHI, Takahiro" , Rob Herring , David Gibson , Catalin Marinas , Will Deacon , David Howells , Vivek Goyal , Herbert Xu , David Miller , dyoung@redhat.com, Baoquan He , Arnd Bergmann , Martin Schwidefsky , Heiko Carstens , prudo@linux.ibm.com, Ard Biesheuvel , James Morse , bhsharma@redhat.com, kexec@lists.infradead.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org, Frank Rowand References: <20180928064841.14117-1-takahiro.akashi@linaro.org> <20180928064841.14117-7-takahiro.akashi@linaro.org> <20181005030849.GK32578@linaro.org> <20181009003733.GN32578@linaro.org> From: Frank Rowand Message-ID: Date: Tue, 9 Oct 2018 10:47:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181009003733.GN32578@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> 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 >>>> wrote: >>>>> >>>>> These functions will be used later to handle kexec-specific properties >>>>> in arm64's kexec_file implementation. >>>>> >>>>> Signed-off-by: AKASHI Takahiro >>>>> Cc: Rob Herring >>>>> Cc: Frank Rowand >>>>> 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 >>>>> #include >>>>> #include >>>>> +#include >>>>> >>>>> #include /* for COMMAND_LINE_SIZE */ >>>>> #include >>>>> @@ -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. 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. -Frank > > Thanks, > -Takahiro Akashi >> >> Rob >