Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933033AbdDQIIZ (ORCPT ); Mon, 17 Apr 2017 04:08:25 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:51809 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932846AbdDQIIV (ORCPT ); Mon, 17 Apr 2017 04:08:21 -0400 Subject: Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events To: Michael Ellerman , Stewart Smith , Madhavan Srinivasan 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> <50380e09-9f5e-d2d4-ce91-26c616b2ce5e@linux.vnet.ibm.com> <87o9w08rdx.fsf@concordia.ellerman.id.au> 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 From: Anju T Sudhakar Date: Mon, 17 Apr 2017 13:38:10 +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: <87o9w08rdx.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17041708-0028-0000-0000-0000076A85E0 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006935; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00848557; UDB=6.00418912; IPR=6.00627198; BA=6.00005290; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015068; XFM=3.00000013; UTC=2017-04-17 08:08:18 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041708-0029-0000-0000-000035279DBE Message-Id: <8aacfd08-8007-172a-3e00-77a3c5bfdb08@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-17_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-1704170075 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2536 Lines: 73 Hi Michael, On Thursday 13 April 2017 05:13 PM, Michael Ellerman wrote: > Anju T Sudhakar writes: >> On Thursday 06 April 2017 02:07 PM, Stewart Smith wrote: >>> Madhavan Srinivasan writes: >>>> --- a/arch/powerpc/platforms/powernv/opal-imc.c >>>> +++ b/arch/powerpc/platforms/powernv/opal-imc.c >>>> @@ -33,6 +33,388 @@ >>> >>>> +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. > That's a really bad hack. > > You can use the compatible property to detect the node you're looking > for, but you need to look at the *value* of the property and check it's > what you expect. Just checking that it's there is fragile. > > cheers > ok. I will rework this code. Thanks, Anju