Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758169AbcCCRdv (ORCPT ); Thu, 3 Mar 2016 12:33:51 -0500 Received: from mail-by2on0067.outbound.protection.outlook.com ([207.46.100.67]:9960 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756532AbcCCRds (ORCPT ); Thu, 3 Mar 2016 12:33:48 -0500 Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=caviumnetworks.com; Message-ID: <56D87572.3090002@caviumnetworks.com> Date: Thu, 3 Mar 2016 09:33:38 -0800 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rob Herring CC: David Daney , Will Deacon , "linux-arm-kernel@lists.infradead.org" , Frank Rowand , Grant Likely , Pawel Moll , Ian Campbell , Kumar Gala , Ganapatrao Kulkarni , Robert Richter , Ard Biesheuvel , Matt Fleming , Mark Rutland , Catalin Marinas , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , David Daney Subject: Re: [PATCH v13 3/6] of, numa: Add NUMA of binding implementation. References: <1456959362-2036-1-git-send-email-ddaney.cavm@gmail.com> <1456959362-2036-4-git-send-email-ddaney.cavm@gmail.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [64.2.3.194] X-ClientProxiedBy: BLUPR07CA085.namprd07.prod.outlook.com (25.160.24.40) To SN1PR07MB2142.namprd07.prod.outlook.com (25.164.47.12) X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2142;2:3q41uVj5I+y8W3rsY8JjS96miZcyE/fggfWBW8LfYWthMbS9PMg4Pz0u76fn0CXnvg4l3HlUHaeQVy58F2uMyny8+JbsUYD6LK3lnyPQElUFWdvALeqM2H2cpgfErKSkgJ8E/i9hET4fy8OX2Czadw==;3:7QXiVT+RxRSmXlTtW/04059ADNzOY+Gfx8vrwm7cIWMhLDcrCa9lE3otgH7j0w19+bq74yr/7dBhvYA50+4Mnb4ROKHfUTh2A3m9ysRbOhtbgNXBJ5Mg+Kb7q1FddI62;25:CFe5Pw1VQaYObiEfotcHHUu8RtWGoA62/e27UMFLrkP56XUF05iNotErETXLeOnq1bSar3MivLj5Mjr9GZRwFu57YTpFRurcJPuNdm4L7NXHW9L9r463fdKEIqDQEa8XpH7g4dAQ+FquVt7iWgLR6B5pv9AHGcGSekGy6Z81neKWw1qgo0eicBJHQHI40QRwV/P4iqmL0oohXFN0F81g7PkELTiLanJPO86q3g/HpgNkwccf8D5YkqwVsVbSKaCoRhSxNieg1Re0xgraATmLmAbthdNeYVDRYWZLfdpAhXLQKgfdo5+GA8XaySoW3Of3pMkCiCSLK5GD445n16wZag== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2142; X-MS-Office365-Filtering-Correlation-Id: 7328e765-87fb-40dd-c5b0-08d34389f8dd X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2142;20:HtOgJYhDF0eOlU0z3diDgcWIVD7Dtkp2g5dKft0FnYpzcTowGmaZMiaz6oCXYaBdXvKOwux7BHEN3uAxb4spy+SbkrI/MU24+PKTBGBXVR1CSsOYKgQ861norJccThbTXSP6UizOD3RSTJMqEmuMYrVArxpBKQsFigziKCBzP+HAidk99zJrwAqzuPSTO7Hxix+arbIlwlkIwPiERLRsVXRZKVu9yDVec9nNQJvwOroa9zA7gafxgZNi0oObZw6cK9y9wByBMjVxYx/Mrh7rytxun07JaKScIKaaRPwwk0EvQKo63Y+XP7BnXkd5l+mLeG/bsvWKwmSRuxuTLGGUdh1328Rs9g6tL6t3jjSEQ4QDa7LD1i1UshW+sg/3jEgut+0e7mTyFi0yoBnw2KrimRRlavjs3Xy1pbJVENL7jSSsBqqMDYxVLqLWaeUexfmFHdgxujzcMLMjKgAKJqEsYOtYJfcjIjv45Y5Xb9wa7r/mr1D0Z04Vv2w/8U64E3BXAeXsMrWEFeyJozo2pNa2Zu0NOhs1dCaRjKXIeob/tEbN4cmw1HvYMt7cKhTiJzqPG2LcfaHavsq4RMdn6hTenUORFKZt96jqIde4GrVrAkc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);SRVR:SN1PR07MB2142;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2142; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2142;4:rZcqAu2gDzNrezYGkLWlgdqs6tCF7Iinz3W+lPYfOZfl5Q14GU7g5sSx4De8ngnDpHMxrdptqJOxQSvsd3H5Fgp8OObZormCDdjxZGr+2GSzWKZMojm1ReSKqoL4R17BnorqRynVSRjqVTEJxFfuRmShEnzdVE9UOHfyxRG0uwCnW2kA29AqV1/XeQ77RsGTXIxwz4ZzlX9WWoWbPtoPJ4DcbeYAdyZ9oIbraCzYeNlSxMPe7mxdwcyQQUTxAljcId5H8koAnSMbeaoM7Yn9sVSuM9n1W/oqUu2e/66h1vJPVHEQlw78OlvpTPX43CqWBP9oJ1xBFQdST/EL64sL56UjU6vuTttvERoRHoJX6ihHMVr/O/g/0IigjapryzmW X-Forefront-PRVS: 0870212862 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(24454002)(479174004)(377454003)(2950100001)(189998001)(23676002)(110136002)(77096005)(15975445007)(122386002)(586003)(6116002)(4326007)(230700001)(5004730100002)(80316001)(81166005)(40100003)(64126003)(87976001)(76176999)(19580405001)(5008740100001)(33656002)(50986999)(19580395003)(36756003)(4001350100001)(2906002)(50466002)(54356999)(92566002)(65816999)(65806001)(87266999)(66066001)(47776003)(53416004)(42186005)(1096002)(2004002);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2142;H:dl.caveonetworks.com;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA3TUIyMTQyOzIzOmphL0lodXB1R2ZGMmtxRGtRU3k1ZCtPMGUw?= =?utf-8?B?TFNWK2ZhR1VRbytaRy95VDA3MlBlYUIrd3U0NzF2NFA3UU14TVRpM24wWEpy?= =?utf-8?B?ajBXSHpreXphUUJvVXhTMExnVGQyNkU3ZjkyZXJWdi9sQ21taGFacHpOSHda?= =?utf-8?B?U3FYMGhWN0xJbUE2UURQbmFHUUdaZitidkJWdTFLQVJ0cENTTGFrRTBTdHpQ?= =?utf-8?B?bXo0MTJINHdUL0tLOFpKVVFzSStnZ29NYkJLcE85RDB0ZUhqeHNGTVhIMnBG?= =?utf-8?B?VGRFLzlsSThlV21Id0hkZi9yV0VpYkxacEJxMzhHSmVONzhZVVhtVU00REU5?= =?utf-8?B?WXMrbjdpanM4SzdXTFVNSnY1RFFPWTVpWXhETGkxMHVSbmxIMG5FUEN4N29P?= =?utf-8?B?Z2xlYWN1azNUTFhkc1g2Z0IzOERXb1ZOYXZrWFJnZnVBbndGNGFQTTBET0Zy?= =?utf-8?B?U0t4NnhXbFZLMk5QTnd3akxOS0l6SFZ5QlRIdGtJdHpQa1RHbTM5aHZreGJ5?= =?utf-8?B?SkNIWDJHdmpIeGM4Sm1VZ3daSU9vemVNSzFaOTc3Q1FtR0JqQWY4WTF2OWdj?= =?utf-8?B?cTVCUFhtY3Bpa1gyUk9sWEhBdW9vUnB2bUVOU3JkenQzS2Zyb2YvLzhkSnhM?= =?utf-8?B?WEsxdEx0cHUrQnVIcXJSb3k4Q1BMaEh1bGQ2Y2NrWmR1ZThBWDQzVHhVeTlB?= =?utf-8?B?M1RaR24zcloxSHJQdWlHWjdhM004dmN4aFMxbHZ1TDZmeGJmV28zUCsrMWFK?= =?utf-8?B?bHNMSUN2UStEZFQwQ3RSRVdEam1nV21IYU15MU43ZXVEOWg0eDlxMm9uTWI2?= =?utf-8?B?UThJOVhOeG1iamwwOVQzTGpoY0lYeWgxcWhJaWYraWQ4ZGdrZzNSb2c1UGN5?= =?utf-8?B?aFNlLzhWcjRVREJkc0lqc2huVEE2ekgyVjRIVGR0MndiY1dQTGlGcy84RnBZ?= =?utf-8?B?Tlp4Z0Vsd081ck1BZXUyWTlGUTlpSVliTWd0YmxxOFdjWFZWMXYzNnhZOTd4?= =?utf-8?B?QTZQUzhWRTBHYnBhL2ZuUUF4bGpsUzBZM0hGbmx6QU1ackxFc2dqNTFrbzRW?= =?utf-8?B?Y0IyNlFnbStnR0pVdlRSU1pWV0xDRnNUMzhqQzZUdVJzUkROelhZd2VKREM2?= =?utf-8?B?MUI4QitkUWt6U3dqbmRlZW53SExwSFEvaGZ6TDBveFFta3djQWZjZ1dSc3o5?= =?utf-8?B?M25wcjJtTytRK3VxVUhOckh5ZFY1aFRUdU5JV2ljSksxcnRHY002cGc3dHVz?= =?utf-8?B?Nk9pSWhLVEpodkFqazFRb0trK2lSbjkvQnZNTWJSdjdGdzVhbGd0dHkwSEcz?= =?utf-8?B?WER3TitURzRPaVF6RTdGcEhBQkJwUjJBbnM0anFxUUJkQTlRMmtvWUsvZlBH?= =?utf-8?B?dU13bk02akpCKzI1RGE4a2ZzcEZ1UFpISEM1SmdrSkVPZDMwSk5BampjbmxV?= =?utf-8?B?VkQrRWtWUTVHYUduN2w1eHdBT1RvcUtDeTZoVThLMytiTVlxaTN6NXoxUTBh?= =?utf-8?Q?GjQC2XemOf7VQdPXXksp7ivYiSlwqeMiy2yHzLQ2UCKyxE?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2142;5:WRMT5UKzU7zTx5oTi4DIFJ7m4ABq2brNU/1KTVde1cX7RnAGkvwuSKc8CWTyK2gkWmLXEWlUPVbjJcoJBby1CI7eldOaFpd1M9W1fEidarv+73+hGYW2E6HbjB5Ek9OnxoNnOuulKQpcIVBqQFWcUA==;24:U5li3I/FtOvZUVaS8gTB/O5PJjDlR/iChTagChXnQv7weMsHLbdMt+ETImq/WcU6BWgws117/SkwQi4T0SKvbfyZoweksfT267+yPCMpzU0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2016 17:33:43.2516 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2142 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 10395 Lines: 337 On 03/02/2016 07:34 PM, Rob Herring wrote: > On Wed, Mar 2, 2016 at 4:55 PM, David Daney wrote: >> From: David Daney >> >> Add device tree parsing for NUMA topology using device >> "numa-node-id" property in distance-map and cpu nodes. >> >> This is a complete rewrite of a previous patch by: >> Ganapatrao Kulkarni >> >> Signed-off-by: David Daney >> --- >> drivers/of/Kconfig | 3 + >> drivers/of/Makefile | 1 + >> drivers/of/of_numa.c | 200 +++++++++++++++++++++++++++++++++++++++++++++++++++ >> include/linux/of.h | 9 +++ >> 4 files changed, 213 insertions(+) >> create mode 100644 drivers/of/of_numa.c >> [...] >> +++ b/drivers/of/of_numa.c >> @@ -0,0 +1,200 @@ >> +/* >> + * OF NUMA Parsing support. >> + * >> + * Copyright (C) 2015 - 2016 Cavium Inc. >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program. If not, see . >> + */ >> + >> +#include >> +#include > > This can be dropped now. Yes. > >> +#include >> + >> +#include >> + >> +/* define default numa node to 0 */ >> +#define DEFAULT_NODE 0 >> + >> +/* >> + * Even though we connect cpus to numa domains later in SMP >> + * init, we need to know the node ids now for all cpus. >> +*/ >> +static void __init of_find_cpu_nodes(void) > > Perhaps of_parse_cpu_nodes for consistency. > > Actually, if all the functions were prefixed with "of_numa_" that > would be better. > OK, I will do that. >> +{ >> + u32 nid; >> + int r; >> + struct device_node *np = NULL; >> + >> + for (;;) { >> + np = of_find_node_by_type(np, "cpu"); >> + if (!np) >> + break; > > Can't we use the child node iterator for /cpus here? I will try to do something like that. > >> + >> + r = of_property_read_u32(np, "numa-node-id", &nid); >> + if (r) >> + continue; >> + >> + pr_debug("NUMA: CPU on %u\n", nid); >> + if (nid >= MAX_NUMNODES) >> + pr_warn("NUMA: Node id %u exceeds maximum value\n", >> + nid); >> + else >> + node_set(nid, numa_nodes_parsed); > > I'm not sure how this works, but don't you need to match this up with > MPIDR of the cpu here? As Ganapatrao said in the other e-mail, all we are doing is discovering which nodes have a CPU here. At this point we don't care about any other properties of the individual CPUs. > >> + } >> +} >> + >> +static void __init of_parse_memory_nodes(void) >> +{ >> + struct device_node *np = NULL; >> + int na, ns; >> + const __be32 *prop; >> + unsigned int psize; >> + u32 nid; >> + u64 base, size; >> + int r; >> + >> + for (;;) { >> + np = of_find_node_by_type(np, "memory"); >> + if (!np) >> + break; >> + >> + r = of_property_read_u32(np, "numa-node-id", &nid); >> + if (r) >> + continue; >> + > >> + prop = of_get_property(np, "reg", &psize); >> + if (!prop) >> + continue; >> + >> + psize /= sizeof(__be32); >> + na = of_n_addr_cells(np); >> + ns = of_n_size_cells(np); >> + >> + if (psize < na + ns) { >> + pr_err("NUMA: memory reg property too small\n"); >> + continue; >> + } >> + base = of_read_number(prop, na); >> + size = of_read_number(prop + na, ns); > > You should be able to use of_address_to_resource for all this. > I thought about doing that. It would make the code simpler. I was concerned about the address translation that is done, but since these are at the root level there should be no translation. I will change the code to do this. >> + >> + pr_debug("NUMA: base = %llx len = %llx, node = %u\n", >> + base, size, nid); >> + >> + if (numa_add_memblk(nid, base, size) < 0) >> + break; >> + } >> + >> + of_node_put(np); >> +} >> + >> +static int __init parse_distance_map_v1(struct device_node *map) >> +{ >> + const __be32 *matrix; >> + unsigned int matrix_size; >> + int entry_count; >> + int i; >> + int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT; > > I believe the defaults are for some old DT files. As this is new, it > should rely on explicit #size-cells in the DT. > > OTOH, what is point of using #size-cells at all versus fixing the > sizes to 1 cell. The documentation doesn't indicate that it uses > #size-cells. That also means that the sizes basically follow the cell > size for the memory given that this is at the top-level. I think we should start with specifying that all elements are a single cell. In the future if this turns out to be insufficient, the binding could easily be extended to include a #node-id-size or something similar. I will simplify the code to assume a single cell. > >> + >> + pr_info("NUMA: parsing numa-distance-map-v1\n"); >> + >> + matrix = of_get_property(map, "distance-matrix", &matrix_size); >> + if (!matrix) { >> + pr_err("NUMA: No distance-matrix property in distance-map\n"); >> + return -EINVAL; >> + } >> + >> + entry_count = matrix_size / (sizeof(__be32) * 3 * nr_size_cells); >> + >> + for (i = 0; i < entry_count; i++) { >> + u32 nodea, nodeb, distance; >> + >> + nodea = of_read_number(matrix, nr_size_cells); >> + matrix += nr_size_cells; >> + nodeb = of_read_number(matrix, nr_size_cells); >> + matrix += nr_size_cells; >> + distance = of_read_number(matrix, nr_size_cells); >> + matrix += nr_size_cells; > > Assuming you fix this to 1 cell, you can use > of_property_count_u32_elems and of_property_read_u32_array. The number of elements in the array could be large. We would have to do dynamic memory allocation to be able to use of_property_read_u32_array. I would prefer to iterate through the array like this to avoid having to allocate memory. > >> + >> + numa_set_distance(nodea, nodeb, distance); >> + pr_debug("NUMA: distance[node%d -> node%d] = %d\n", >> + nodea, nodeb, distance); >> + >> + /* Set default distance of node B->A same as A->B */ >> + if (nodeb > nodea) >> + numa_set_distance(nodeb, nodea, distance); >> + } >> + >> + return 0; >> +} >> + >> +static int __init of_parse_distance_map(void) >> +{ >> + int ret = -EINVAL; >> + struct device_node *np = of_find_node_by_name(NULL, "distance-map"); >> + >> + if (!np) >> + return ret; >> + >> + if (of_device_is_compatible(np, "numa-distance-map-v1")) { > > You can use of_find_compatible_node() instead of these 2 calls. Well, we need to match exactly the name "distance-map", of_find_compatible_node() doesn't match on the name, so I think we need two checks, one for name and one for compatible. > >> + ret = parse_distance_map_v1(np); >> + goto out; >> + } >> + >> + pr_err("NUMA: invalid distance-map device node\n"); >> +out: >> + of_node_put(np); >> + return ret; >> +} >> + >> +int of_node_to_nid(struct device_node *device) >> +{ >> + struct device_node *np; >> + u32 nid; >> + int r = -ENODATA; >> + >> + np = of_node_get(device); >> + >> + while (np) { >> + struct device_node *parent; >> + >> + r = of_property_read_u32(np, "numa-node-id", &nid); >> + if (r != -EINVAL) > > You want to break for other err values? Yes, if the property doesn't exist, we need to check the parent. Otherwise, it indicates an error in the device tree, and we bail out with the warning message. I will add a comment that explains what we are doing and the significance of -EINVAL > >> + break; >> + >> + /* property doesn't exist in this node, look in parent */ >> + parent = of_get_parent(np); >> + of_node_put(np); >> + np = parent; >> + } >> + if (np && r) >> + pr_warn("NUMA: Invalid \"numa-node-id\" property in node %s\n", >> + np->name); >> + of_node_put(np); >> + >> + if (!r) { >> + if (nid >= MAX_NUMNODES) >> + pr_warn("NUMA: Node id %u exceeds maximum value\n", >> + nid); >> + else >> + return nid; >> + } >> + >> + return NUMA_NO_NODE; >> +} > > Needs to be exported? Good catch. I will export it. > >> + >> +int __init of_numa_init(void) >> +{ >> + of_find_cpu_nodes(); >> + of_parse_memory_nodes(); >> + return of_parse_distance_map(); >> +} >> diff --git a/include/linux/of.h b/include/linux/of.h >> index dc6e396..fe67a4c 100644 >> --- a/include/linux/of.h >> +++ b/include/linux/of.h >> @@ -685,6 +685,15 @@ static inline int of_node_to_nid(struct device_node *device) >> } >> #endif >> >> +#ifdef CONFIG_OF_NUMA >> +extern int of_numa_init(void); >> +#else >> +static inline int of_numa_init(void) >> +{ >> + return -ENOSYS; >> +} >> +#endif >> + >> static inline struct device_node *of_find_matching_node( >> struct device_node *from, >> const struct of_device_id *matches) >> -- >> 1.8.3.1 >>