linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
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: Wed, 22 Jul 2015 14:07:44 +1000	[thread overview]
Message-ID: <1437538064.30906.20.camel@axtens.net> (raw)
In-Reply-To: <1437045206-7491-5-git-send-email-maddy@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3577 bytes --]

 
>  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.

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?
 - 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".
> +		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>"?
> +			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...?
> +	}
> +
> +	return 0;
> +}


-- 
Regards,
Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 860 bytes --]

  reply	other threads:[~2015-07-22  4:09 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 [this message]
2015-07-23  6:03     ` Madhavan Srinivasan
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=1437538064.30906.20.camel@axtens.net \
    --to=dja@axtens.net \
    --cc=anton@samba.org \
    --cc=eranian@google.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --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).