All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 5/12] Update firmware_has_feature() to check architecture bits
Date: Tue, 23 Apr 2013 13:56:16 -0500	[thread overview]
Message-ID: <5176D950.9010507@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130423115002.3d321e6a69ed97d134127a2b@canb.auug.org.au>

On 04/22/2013 08:50 PM, Stephen Rothwell wrote:
> Hi Nathan,
> 
> On Mon, 22 Apr 2013 13:38:47 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>>
>> -/* Option vector 5: PAPR/OF options supported */
>> -#define OV5_LPAR		0x80	/* logical partitioning supported */
>> -#define OV5_SPLPAR		0x40	/* shared-processor LPAR supported */
>> +/* Option vector 5: PAPR/OF options supported
>> + * Thses bits are also used for the platform_has_feature() call so
>       ^^^^^
> typo

will fix.

> 
>> + * we encode the vector index in the define and use the OV5_FEAT()
>> + * and OV5_INDX() macros to extract the desired information.
>> + */
>> +#define OV5_FEAT(x)	((x) & 0xff)
>> +#define OV5_INDX(x)	((x) >> 8)
>> +#define OV5_LPAR		0x0280	/* logical partitioning supported */
>> +#define OV5_SPLPAR		0x0240	/* shared-processor LPAR supported */
> 
> Wouldn't it be clearer to say
> 
> #define OV5_LPAR	(OV5_INDX(0x2) | OV5_FEAT(0x80))

The defines won't work the way you used them, they were designed to take the
combined value, i.e. 0x0280, and parse out the index and the feature.

I do think having macros to create the actual values as your example does is easier
to read. We could do something like...

#define OV5_FEAT(x)	((x) & 0xff)
#define OV5_SETINDX(x)	((x) << 8)
#define OV5_GETINDX(x)	((x) >> 8)

#define OV5_LPAR	(OV5_SETINDX(0x2) | OV5_FEAT(0x80))

Thoughts?

> 
> etc?
> 
>> @@ -145,6 +141,7 @@
>>   * followed by # option vectors - 1, followed by the option vectors.
>>   */
>>  extern unsigned char ibm_architecture_vec[];
>> +bool platform_has_feature(unsigned int);
> 
> "extern", please (if nothing else, for consistency).
> 

That shouldn't really be there, its an artifact from a previous patch. I'll remove it.

>> +static __initdata struct vec5_fw_feature
>> +vec5_fw_features_table[FIRMWARE_MAX_FEATURES] = {
> 
> Why make this array FIRMWARE_MAX_FEATURES (63) long?  You could just
> restrict the for loop below to ARRAY_SIZE(vec5_fw_features_table).
> 
>> +	{FW_FEATURE_TYPE1_AFFINITY,	OV5_TYPE1_AFFINITY},
>> +};
>> +
>> +void __init fw_vec5_feature_init(const char *vec5, unsigned long len)
>> +{
>> +	unsigned int index, feat;
>> +	int i;
>> +
>> +	pr_debug(" -> fw_vec5_feature_init()\n");
>> +
>> +	for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) {
>> +		if (!vec5_fw_features_table[i].feature)
>> +			continue;
> 
> And this test could go away.
> 
> I realise that you have just copied the existing code, but you should not
> do that blindly.  Maybe you could even add an (earlier) patch that fixes
> the existing code.

I think that could be done easily enough.

Thanks for looking,
-Nathan

  reply	other threads:[~2013-04-23 18:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-22 17:54 [PATCH v3 0/12] NUMA CPU Reconfiguration using PRRN Nathan Fontenot
2013-04-22 18:30 ` [PATCH v3 1/12] Create a powerpc update_devicetree interface Nathan Fontenot
2013-04-23  0:15   ` Benjamin Herrenschmidt
2013-04-23 18:46     ` Nathan Fontenot
2013-04-23 20:54       ` Benjamin Herrenschmidt
2013-04-22 18:31 ` [PATCH v3 2/12] Correct buffer parsing in update-properties Nathan Fontenot
2013-04-22 18:33 ` [PATCH v3 3/12] Add PRRN event handler Nathan Fontenot
2013-04-22 18:35 ` [PATCH v3 4/12] Move architecture vector definitions to prom.h Nathan Fontenot
2013-04-23  0:18   ` Benjamin Herrenschmidt
2013-04-22 18:38 ` [PATCH v3 5/12] Update firmware_has_feature() to check architecture bits Nathan Fontenot
2013-04-23  1:50   ` Stephen Rothwell
2013-04-23 18:56     ` Nathan Fontenot [this message]
2013-04-23  1:52   ` Stephen Rothwell
2013-04-22 18:40 ` [PATCH v3 6/12] Update numa.c to use updated firmware_has_feature() Nathan Fontenot
2013-04-22 18:41 ` [PATCH v3 7/12] Use stop machine to update cpu maps Nathan Fontenot
2013-04-23  0:24   ` Benjamin Herrenschmidt
2013-04-23 18:58     ` Nathan Fontenot
2013-04-22 18:44 ` [PATCH v3 8/12] " Nathan Fontenot
2013-04-22 18:45 ` [PATCH v3 9/12] Update NUMA VDSO information Nathan Fontenot
2013-04-22 18:46 ` [PATCH v3 10/12] Re-enable Virtual Private Home Node capabilities Nathan Fontenot
2013-04-22 18:47 ` [PATCH v3 11/12] Enable PRRN Event handling Nathan Fontenot
2013-04-22 18:47 ` [PATCH v3 12/12] Add /proc interface to control topology updates Nathan Fontenot
2013-04-23  2:00   ` Stephen Rothwell
2013-04-23  2:49     ` Michael Ellerman
2013-04-23 18:59       ` Nathan Fontenot
2013-04-23  2:02   ` Stephen Rothwell

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=5176D950.9010507@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sfr@canb.auug.org.au \
    /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.