Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp675418imd; Thu, 1 Nov 2018 03:53:38 -0700 (PDT) X-Google-Smtp-Source: AJdET5emcU5rN9Qz+DX/fAwPuNZK/sfjOFzH/Hlo7wYzoOFbKcKbdkvnkrjNjumRGcpOOydLRq4o X-Received: by 2002:a63:63c3:: with SMTP id x186mr6762990pgb.330.1541069618546; Thu, 01 Nov 2018 03:53:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541069618; cv=none; d=google.com; s=arc-20160816; b=CE/ycXrJoyG4Uh7CewJnuLYufWGSkmc+OytWUfO4OXfA+ve6jawUT1nlIPoGeTUpD4 a4s+i9Sb1ROpDjclAsnVvsimYmoVbm+ZlZnaFfSnBSVAFA3f6qUR6Yt7DXMPgnPaUPss ztPxQsng48TN5C5QDAlvVCtRLWjs5An0/JF6JvJ7unQtcvtTpyPMAE9M3iSTCGWf5Vkw UT/Vnf/Erk2CaqF+a6aZyfl1XpUpTdHDoR8xpkOEO5JlOux7VaoP82TH/SbHsp5xlP/a 92Xpyc8F6bcmM1nXx5Cn5MbT9/+OKdCP+/Y+DWHcPBypI/e22ihvf5RbcF1gyP1I8okh uwsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=QD9vdEEKRf1YUTRk5hHmZ2p9rhx3jqsAMLjpDXtGtow=; b=JNWOVk59p6MV8LXSaUa9VaQJQ/ojBA3Awot9oHntbGXV6O6Pw5SzqCk5FAjMhEW9Gp Ka4Y/abI69DSOXaH0e3LKrrUyatxgLsJ4C5g0XnG7ulY3hDzaPdsBj2ASwnGYmUv3HM6 juOhBv4N3tuLujXkIWyWetfmFR+abwcAfL9E20b4CLbNf5E7uml++5Uga4iU+rzoyunN OkGLiDa6PIcnsu9yURqvAFh7Bb31DuGxC4xG4Dx///+vUT4gx38avEsLQFFB3LB/9nsi vE0OALfy3oi4haVa3dhjggKruqfIfjPh2ema95bTcsm8OPoB2FZh6IO0uriq2DV06DYH PR9g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q201-v6si14664353pfq.14.2018.11.01.03.53.23; Thu, 01 Nov 2018 03:53:38 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727963AbeKATz3 (ORCPT + 99 others); Thu, 1 Nov 2018 15:55:29 -0400 Received: from ozlabs.org ([203.11.71.1]:57969 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726520AbeKATz3 (ORCPT ); Thu, 1 Nov 2018 15:55:29 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 42m29S65HXz9sSq; Thu, 1 Nov 2018 21:53:00 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Rob Herring Cc: devicetree@vger.kernel.org, Linux Kernel Mailing List , linuxppc-dev@lists.ozlabs.org, Frank Rowand , Tyrel Datwyler Subject: Re: [PATCH 01/21] of: Add cpu node iterator for_each_of_cpu_node() In-Reply-To: References: <20180905193738.19325-1-robh@kernel.org> <20180905193738.19325-2-robh@kernel.org> <874ld3jz6v.fsf@concordia.ellerman.id.au> <871s87jz3g.fsf@concordia.ellerman.id.au> Date: Thu, 01 Nov 2018 21:52:57 +1100 Message-ID: <87tvl1dq7q.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rob Herring writes: > On Tue, Oct 30, 2018 at 9:20 AM Michael Ellerman wrote: >> >> Michael Ellerman writes: >> > Hi Rob, >> > >> > Sorry I missed this when you posted it. >> > >> > Rob Herring writes: >> >> Iterating thru cpu nodes is a common pattern. Create a common iterator >> >> which can find child nodes either by node name or device_type == cpu. >> >> Using the former will allow for eventually dropping device_type >> >> properties which are deprecated for FDT. >> > >> > Device trees we see on powerpc generally don't (never?) use "cpu" as the >> > node name for CPU nodes. And many of those device trees come from >> > firmware, so we can't update them. >> > >> > So dropping support for device_type is a non-starter from our POV. >> >> ps. presumably that's what you meant by deprecated *for FDT*. > > Right. > >> But anyway just wanted to make sure we are on the same page. > > Yes, I was aware at least older powerpc DTs don't use 'cpu' for node names. Actually newer ones too, see below :) And there's code out there that expects this, so we can't realistically change it any time soon :/ https://github.com/ibm-power-utilities/powerpc-utils/blob/master/src/drmgr/common_cpu.c#L186 https://github.com/ibm-power-utilities/powerpc-utils/blob/master/src/ppc64_cpu.c#L344 cheers $ ls -d1 /proc/device-tree/cpus/PowerPC\,POWER9@* /proc/device-tree/cpus/PowerPC,POWER9@14 /proc/device-tree/cpus/PowerPC,POWER9@1c /proc/device-tree/cpus/PowerPC,POWER9@34 /proc/device-tree/cpus/PowerPC,POWER9@3c /proc/device-tree/cpus/PowerPC,POWER9@4 /proc/device-tree/cpus/PowerPC,POWER9@48 /proc/device-tree/cpus/PowerPC,POWER9@54 /proc/device-tree/cpus/PowerPC,POWER9@804 /proc/device-tree/cpus/PowerPC,POWER9@80c /proc/device-tree/cpus/PowerPC,POWER9@814 /proc/device-tree/cpus/PowerPC,POWER9@81c /proc/device-tree/cpus/PowerPC,POWER9@834 /proc/device-tree/cpus/PowerPC,POWER9@83c /proc/device-tree/cpus/PowerPC,POWER9@844 /proc/device-tree/cpus/PowerPC,POWER9@84c /proc/device-tree/cpus/PowerPC,POWER9@c