From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
To: Daniel Axtens <dja@axtens.net>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Stephane Eranian <eranian@google.com>,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [PATCH v5 4/7] powerpc/powernv: detect supported nest pmus and its events
Date: Thu, 23 Jul 2015 11:33:14 +0530 [thread overview]
Message-ID: <55B083A2.4030404@linux.vnet.ibm.com> (raw)
In-Reply-To: <1437538064.30906.20.camel@axtens.net>
On Wednesday 22 July 2015 09:37 AM, Daniel Axtens wrote:
>
>> static struct perchip_nest_info p8_nest_perchip_info[P8_NEST_MAX_CHIPS];
>> +static struct nest_pmu *per_nest_pmu_arr[P8_NEST_MAX_PMUS];
>> +
>> +static int nest_event_info(struct property *pp, char *name,
>> + struct nest_ima_events *p8_events, int string, u32 val)
> 'int string' is a bit confusing. 'bool is_string' might be clearer, but
> I think it would be even better still to have different functions for
> string and non-string cases, especially because you only need val in the
> non-string case.
I would perfer to be a single function, since most of the code is same
just of the sting or val part. yes. We can make is as is_string and will
add
comment explaining what is done here?
> That will also allow you to give the functions clearer names. I think
> the function is populating the event with info from the dt property (in
> the string case) or the val argument (non-string case) - maybe the names
> could reflect that somehow?
>> +{
>> + char *buf;
>> +
>
>> +
>> +static int nest_pmu_create(struct device_node *dev, int pmu_index)
>> +{
>> + struct nest_ima_events **p8_events_arr, *p8_events;
>> + struct nest_pmu *pmu_ptr;
>> + struct property *pp;
>> + char *buf, *start;
>> + const __be32 *lval;
>> + u32 val;
>> + int idx = 0, ret;
>> +
>> + if (!dev)
>> + return -EINVAL;
>> +
>> + /* memory for nest pmus */
>> + pmu_ptr = kzalloc(sizeof(struct nest_pmu), GFP_KERNEL);
>> + if (!pmu_ptr)
>> + return -ENOMEM;
>> +
>> + /* Needed for hotplug/migration */
>> + per_nest_pmu_arr[pmu_index] = pmu_ptr;
>> +
>> + /* memory for nest pmu events */
>> + p8_events_arr = kzalloc((sizeof(struct nest_ima_events) * 64),
>> + GFP_KERNEL);
>> + if (!p8_events_arr)
>> + return -ENOMEM;
>> + p8_events = (struct nest_ima_events *)p8_events_arr;
> I'm still quite uncomfortable with this.
> - Why * 64? Should it be * P8_NEST_MAX_EVENTS_SUPPORTED? Or is it a
> different constant?
Yes it should be P8_NEST_MAX_EVENTS_SUPPORTED, and it should be
define as 64. Missed it to replace the macro. Nice catch.
> - p8_events = p8_events_arr[0] would be clearer
>
>> +
>> + /*
>> + * Loop through each property
>> + */
>> + for_each_property_of_node(dev, pp) {
>> + start = pp->name;
>> +
>> + if (!strcmp(pp->name, "name")) {
>> + if (!pp->value ||
>> + (strnlen(pp->value, pp->length) == pp->length) ||
>> + (pp->length > P8_NEST_MAX_PMU_NAME_LEN))
>> + return -EINVAL;
>> +
>> + buf = kzalloc(P8_NEST_MAX_PMU_NAME_LEN, GFP_KERNEL);
>> + if (!buf)
>> + return -ENOMEM;
>> +
>> + /* Save the name to register it later */
>> + sprintf(buf, "Nest_%s", (char *)pp->value);
>> + pmu_ptr->pmu.name = (char *)buf;
>> + continue;
>> + }
>> +
>> + /* Skip these, we dont need it */
> "don't" instead of "dont".
Will change it.
>> + if (!strcmp(pp->name, "phandle") ||
>> + !strcmp(pp->name, "device_type") ||
>> + !strcmp(pp->name, "linux,phandle"))
>> + continue;
>> +
>> + if (strncmp(pp->name, "unit.", 5) == 0) {
>> + /* Skip first few chars in the name */
> The whole comment is pretty uninformative, as is the similar comment
> below. If you need a comment at all, maybe something along the lines of
> "Strip the prefix because <reason we don't need/want the prefix>"?
Yes will change it. Thanks
>> + start += 5;
>> + ret = nest_event_info(pp, start, p8_events++, 1, 0);
>> + } else if (strncmp(pp->name, "scale.", 6) == 0) {
>> + /* Skip first few chars in the name */
>> + start += 6;
>> + ret = nest_event_info(pp, start, p8_events++, 1, 0);
>> + } else {
>> + lval = of_get_property(dev, pp->name, NULL);
>> + val = (uint32_t)be32_to_cpup(lval);
>> +
>> + ret = nest_event_info(pp, start, p8_events++, 0, val);
>> + }
>> +
>> + if (ret)
>> + return ret;
>> +
>> + /* book keeping */
>> + idx++;
> You don't seem to use idx in this function, apart from incrementing it
> here...?
Used in next patch.
>> + }
>> +
>> + return 0;
>> +}
>
next prev parent reply other threads:[~2015-07-23 6:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 11:13 [PATCH v5 0/7]powerpc/powernv: Nest Instrumentation support Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 1/7] powerpc/powernv: Data structure and macros definition Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 2/7] powerpc/powernv: Add OPAL support for Nest PMU Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 3/7] powerpc/powernv: Nest PMU detection and device tree parser Madhavan Srinivasan
2015-07-22 3:49 ` Daniel Axtens
2015-07-23 5:54 ` Madhavan Srinivasan
2015-07-23 9:16 ` Michael Ellerman
2015-07-23 9:26 ` Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 4/7] powerpc/powernv: detect supported nest pmus and its events Madhavan Srinivasan
2015-07-22 4:07 ` Daniel Axtens
2015-07-23 6:03 ` Madhavan Srinivasan [this message]
2015-07-23 9:11 ` Michael Ellerman
2015-07-23 9:23 ` Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 5/7] powerpc/powernv: add event attribute and group to nest pmu Madhavan Srinivasan
2015-07-22 4:44 ` Daniel Axtens
2015-07-23 6:32 ` Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 6/7] powerpc/powernv: generic nest pmu event functions Madhavan Srinivasan
2015-07-22 4:56 ` Daniel Axtens
2015-07-23 6:44 ` Madhavan Srinivasan
2015-07-23 9:04 ` Michael Ellerman
2015-07-23 9:22 ` Madhavan Srinivasan
2015-07-16 11:13 ` [PATCH v5 7/7] powerpc/powernv: nest pmu cpumask and cpu hotplug support Madhavan Srinivasan
2015-07-22 5:03 ` Daniel Axtens
2015-07-23 6:48 ` Madhavan Srinivasan
2015-07-23 6:49 ` Daniel Axtens
2015-07-23 7:25 ` Madhavan Srinivasan
2015-07-20 18:43 ` [PATCH v5 0/7]powerpc/powernv: Nest Instrumentation support Sukadev Bhattiprolu
2015-07-23 6:44 ` Madhavan Srinivasan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B083A2.4030404@linux.vnet.ibm.com \
--to=maddy@linux.vnet.ibm.com \
--cc=anton@samba.org \
--cc=dja@axtens.net \
--cc=eranian@google.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=sukadev@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).