From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S934267AbdDFJd0 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 6 Apr 2017 05:33:26 -0400
Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:42244 "EHLO
        mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S932446AbdDFJdM (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 6 Apr 2017 05:33:12 -0400
Subject: Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and
 its events
To: Stewart Smith <stewart@linux.vnet.ibm.com>,
        Madhavan Srinivasan <maddy@linux.vnet.ibm.com>, mpe@ellerman.id.au
References: <1491231308-15282-1-git-send-email-maddy@linux.vnet.ibm.com>
 <1491231308-15282-4-git-send-email-maddy@linux.vnet.ibm.com>
 <87r316hqy9.fsf@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
        ego@linux.vnet.ibm.com, bsingharora@gmail.com,
        benh@kernel.crashing.org, paulus@samba.org, anton@samba.org,
        sukadev@linux.vnet.ibm.com, mikey@neuling.org, dja@axtens.net,
        eranian@google.com, Hemant Kumar <hemant@linux.vnet.ibm.com>
From: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Date: Thu, 6 Apr 2017 15:03:00 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <87r316hqy9.fsf@linux.vnet.ibm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-TM-AS-GCONF: 00
x-cbid: 17040609-0012-0000-0000-000014018626
X-IBM-SpamModules-Scores: 
X-IBM-SpamModules-Versions: BY=3.00006887; HX=3.00000240; KW=3.00000007;
 PH=3.00000004; SC=3.00000208; SDB=6.00843837; UDB=6.00415819; IPR=6.00622020;
 BA=6.00005271; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000;
 ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014931; XFM=3.00000013;
 UTC=2017-04-06 09:33:09
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
x-cbparentid: 17040609-0013-0000-0000-00004CC76D7F
Message-Id: <50380e09-9f5e-d2d4-ce91-26c616b2ce5e@linux.vnet.ibm.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-06_07:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0
 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001
 definitions=main-1704060080
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Stewart,


Thanks for the review.


On Thursday 06 April 2017 02:07 PM, Stewart Smith wrote:
> Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes:
>> --- a/arch/powerpc/platforms/powernv/opal-imc.c
>> +++ b/arch/powerpc/platforms/powernv/opal-imc.c
>> @@ -33,6 +33,388 @@
> <snip>
>> +static void imc_pmu_setup(struct device_node *parent)
>> +{
>> +	struct device_node *child;
>> +	int pmu_count = 0, rc = 0;
>> +	const struct property *pp;
>> +
>> +	if (!parent)
>> +		return;
>> +
>> +	/* Setup all the IMC pmus */
>> +	for_each_child_of_node(parent, child) {
>> +		pp = of_get_property(child, "compatible", NULL);
>> +		if (pp) {
>> +			/*
>> +			 * If there is a node with a "compatible" field,
>> +			 * that's a PMU node
>> +			 */
>> +			rc = imc_pmu_create(child, pmu_count);
>> +			if (rc)
>> +				return;
>> +			pmu_count++;
>> +		}
>> +	}
>> +}
> This doesn't strike me as the right kind of structure, the presence of a
> compatible property really just says "hey, there's this device and it's
> compatible with these ways of accessing it".
>
> I'm guessing the idea behind having imc-nest-offset/size in a top level
> node is because it's common to everything under it and the aim is to not
> blow up the device tree to be enormous.
>
> So why not go after each ibm,imc-counters-nest compatible node under the
> top level ibm,opal-in-memory-counters node? (i'm not convinced that
> having ibm,ibmc-counters-nest versus ibm,imc-counters-core and
> ibm,imc-counters-thread as I see in the dts is correct though, as
> they're all accessed exactly the same way?)
>

The idea here is, we have one directory which contains common events 
information for nest(same incase of core and thread), and one directory 
for each nest(/core/thread) pmu.
So while parsing we need to make sure that the node which we are parsing 
is the pmu node, not the node which contains the common event 
information. We use the "compatible" property here for that purpose. 
Because we don't have a compatible property for the node which contains 
events info.




Regards,
Anju