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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.