All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, sparclinux@vger.kernel.org,
	microblaze-uclinux@itee.uq.edu.au, benh@kernel.crashing.org,
	sfr@canb.auug.org.au, monstr@monstr.eu
Subject: Re: [PATCH 11/11] of: unify phandle name in struct device_node
Date: Tue, 24 Nov 2009 13:33:22 -0700	[thread overview]
Message-ID: <fa686aa40911241233k7c6d428g8f70f00abdd754e8@mail.gmail.com> (raw)
In-Reply-To: <20091124.093732.203692950.davem@davemloft.net>

On Tue, Nov 24, 2009 at 10:37 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 24 Nov 2009 01:20:05 -0700
>
>> In struct device_node, the phandle is named 'linux_phandle' for PowerPC
>> and MicroBlaze, and 'node' for SPARC.  There is no good reason for the
>> difference, it is just an artifact of the code diverging over a couple
>> of years.  This patch renames .node to .linux_phandle for SPARC.
>
> I know it's just a name, but there is no reason to put "linux" in the
> member name.  It's the real device phandle value from OpenFirmware not
> something invented by Linux's OF layer.

I agree, and I also considered renaming it to simply 'phandle' or to
change the powerpc code back to using .node everywhere (more on .node
usage in powerpc below).  I didn't want to use .node because .node is
pretty generic, and is used in other places for different things.
Basically I wanted to avoid confusion.  In particular, .node points to
a device_node, not a phandle, in struct of_device.  Changing all
references to simply 'phandle' seems to be the best, but it does
require changes to more locations in the code.  In the end I decided
on some constructive lazyness by settling for the already-used
.linux_phandle so that I would need to touch as many files, but still
retain a unique name that is easy to find.  If you prefer, I can
change it all to simply '.phandle'.

> PowerPC uses this for something different, it records the information
> here using the special "linux,phandle" and "ibm,phandle" properties.

Agreed, the phandle isn't a real phandle when using the flat tree.
However, though the source of the phandle value is different, the use
case is identical, so it make sense to stuff it into the same member.
Merging them lets me unify more code.  For example,
of_find_node_by_phandle().

> See unflatten_dt_node() in arch/powerpc/kernel/prom.c before your
> changes.

Yup, I looked at this.  The unflatten code stuffs both linux,phandle
and ibm,phandle into .linux_phandle, and linux,phandle also gets
stuffed into .node.  But all the users except one use the
.linux_phandle, not .node, and that remaining user *I think* can
safely use .linux_phandle too.

Thanks for the review,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, sparclinux@vger.kernel.org,
	microblaze-uclinux@itee.uq.edu.au, benh@kernel.crashing.org,
	sfr@canb.auug.org.au, monstr@monstr.eu
Subject: Re: [PATCH 11/11] of: unify phandle name in struct device_node
Date: Tue, 24 Nov 2009 20:33:22 +0000	[thread overview]
Message-ID: <fa686aa40911241233k7c6d428g8f70f00abdd754e8@mail.gmail.com> (raw)
In-Reply-To: <20091124.093732.203692950.davem@davemloft.net>

On Tue, Nov 24, 2009 at 10:37 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 24 Nov 2009 01:20:05 -0700
>
>> In struct device_node, the phandle is named 'linux_phandle' for PowerPC
>> and MicroBlaze, and 'node' for SPARC.  There is no good reason for the
>> difference, it is just an artifact of the code diverging over a couple
>> of years.  This patch renames .node to .linux_phandle for SPARC.
>
> I know it's just a name, but there is no reason to put "linux" in the
> member name.  It's the real device phandle value from OpenFirmware not
> something invented by Linux's OF layer.

I agree, and I also considered renaming it to simply 'phandle' or to
change the powerpc code back to using .node everywhere (more on .node
usage in powerpc below).  I didn't want to use .node because .node is
pretty generic, and is used in other places for different things.
Basically I wanted to avoid confusion.  In particular, .node points to
a device_node, not a phandle, in struct of_device.  Changing all
references to simply 'phandle' seems to be the best, but it does
require changes to more locations in the code.  In the end I decided
on some constructive lazyness by settling for the already-used
.linux_phandle so that I would need to touch as many files, but still
retain a unique name that is easy to find.  If you prefer, I can
change it all to simply '.phandle'.

> PowerPC uses this for something different, it records the information
> here using the special "linux,phandle" and "ibm,phandle" properties.

Agreed, the phandle isn't a real phandle when using the flat tree.
However, though the source of the phandle value is different, the use
case is identical, so it make sense to stuff it into the same member.
Merging them lets me unify more code.  For example,
of_find_node_by_phandle().

> See unflatten_dt_node() in arch/powerpc/kernel/prom.c before your
> changes.

Yup, I looked at this.  The unflatten code stuffs both linux,phandle
and ibm,phandle into .linux_phandle, and linux,phandle also gets
stuffed into .node.  But all the users except one use the
.linux_phandle, not .node, and that remaining user *I think* can
safely use .linux_phandle too.

Thanks for the review,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: David Miller <davem@davemloft.net>
Cc: sfr@canb.auug.org.au, monstr@monstr.eu,
	microblaze-uclinux@itee.uq.edu.au,
	devicetree-discuss@lists.ozlabs.org, sparclinux@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 11/11] of: unify phandle name in struct device_node
Date: Tue, 24 Nov 2009 13:33:22 -0700	[thread overview]
Message-ID: <fa686aa40911241233k7c6d428g8f70f00abdd754e8@mail.gmail.com> (raw)
In-Reply-To: <20091124.093732.203692950.davem@davemloft.net>

On Tue, Nov 24, 2009 at 10:37 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Tue, 24 Nov 2009 01:20:05 -0700
>
>> In struct device_node, the phandle is named 'linux_phandle' for PowerPC
>> and MicroBlaze, and 'node' for SPARC. =A0There is no good reason for the
>> difference, it is just an artifact of the code diverging over a couple
>> of years. =A0This patch renames .node to .linux_phandle for SPARC.
>
> I know it's just a name, but there is no reason to put "linux" in the
> member name. =A0It's the real device phandle value from OpenFirmware not
> something invented by Linux's OF layer.

I agree, and I also considered renaming it to simply 'phandle' or to
change the powerpc code back to using .node everywhere (more on .node
usage in powerpc below).  I didn't want to use .node because .node is
pretty generic, and is used in other places for different things.
Basically I wanted to avoid confusion.  In particular, .node points to
a device_node, not a phandle, in struct of_device.  Changing all
references to simply 'phandle' seems to be the best, but it does
require changes to more locations in the code.  In the end I decided
on some constructive lazyness by settling for the already-used
.linux_phandle so that I would need to touch as many files, but still
retain a unique name that is easy to find.  If you prefer, I can
change it all to simply '.phandle'.

> PowerPC uses this for something different, it records the information
> here using the special "linux,phandle" and "ibm,phandle" properties.

Agreed, the phandle isn't a real phandle when using the flat tree.
However, though the source of the phandle value is different, the use
case is identical, so it make sense to stuff it into the same member.
Merging them lets me unify more code.  For example,
of_find_node_by_phandle().

> See unflatten_dt_node() in arch/powerpc/kernel/prom.c before your
> changes.

Yup, I looked at this.  The unflatten code stuffs both linux,phandle
and ibm,phandle into .linux_phandle, and linux,phandle also gets
stuffed into .node.  But all the users except one use the
.linux_phandle, not .node, and that remaining user *I think* can
safely use .linux_phandle too.

Thanks for the review,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2009-11-24 20:33 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24  8:17 [PATCH 00/11] Yet another series of OF merge patches Grant Likely
2009-11-24  8:17 ` Grant Likely
2009-11-24  8:17 ` Grant Likely
2009-11-24  8:17 ` [PATCH 01/11] of/flattree: Merge early_init_dt_check_for_initrd() Grant Likely
2009-11-24  8:17   ` Grant Likely
2009-11-24  8:17   ` Grant Likely
2009-11-26  3:51   ` Benjamin Herrenschmidt
2009-11-26  3:51     ` [PATCH 01/11] of/flattree: Merge Benjamin Herrenschmidt
2009-11-26  4:02     ` [PATCH 01/11] of/flattree: Merge early_init_dt_check_for_initrd() Grant Likely
2009-11-26  4:02       ` Grant Likely
2009-11-26  4:02       ` Grant Likely
2009-11-24  8:18 ` [PATCH 02/11] of/flattree: Merge earlyinit_dt_scan_root() Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-26  3:54   ` Benjamin Herrenschmidt
2009-11-26  3:54     ` Benjamin Herrenschmidt
2009-11-26  3:54     ` Benjamin Herrenschmidt
2009-11-26  4:03     ` Grant Likely
2009-11-26  4:03       ` Grant Likely
2009-11-26  4:03       ` Grant Likely
2009-11-24  8:18 ` [PATCH 03/11] of/flattree: merge dt_mem_next_cell Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-26  3:55   ` Benjamin Herrenschmidt
2009-11-26  3:55     ` Benjamin Herrenschmidt
2009-11-26  3:55     ` Benjamin Herrenschmidt
2009-11-24  8:18 ` [PATCH 04/11] of/flattree: eliminate cell_t typedef Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-26  3:59   ` Benjamin Herrenschmidt
2009-11-26  3:59     ` Benjamin Herrenschmidt
2009-11-26  3:59     ` Benjamin Herrenschmidt
2009-11-26  4:05     ` Grant Likely
2009-11-26  4:05       ` Grant Likely
2009-11-26  4:05       ` Grant Likely
2009-11-26  5:27       ` Benjamin Herrenschmidt
2009-11-26  5:27         ` Benjamin Herrenschmidt
2009-11-26 21:36         ` Segher Boessenkool
2009-11-26 21:36           ` Segher Boessenkool
2009-11-26 21:36           ` Segher Boessenkool
2009-11-26 21:40           ` Benjamin Herrenschmidt
2009-11-26 21:40             ` Benjamin Herrenschmidt
2009-11-26 21:40             ` Benjamin Herrenschmidt
2009-11-26 23:32           ` David Miller
2009-11-26 23:32             ` David Miller
2009-11-26 23:32             ` David Miller
2009-12-11  6:43         ` Grant Likely
2009-12-11  6:43           ` Grant Likely
2009-12-11  6:43           ` Grant Likely
     [not found]       ` <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-11-26  6:28         ` M. Warner Losh
2009-11-26  6:28           ` M. Warner Losh
2009-11-26  6:28           ` M. Warner Losh
     [not found]           ` <20091125.232818.-1350498258.imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org>
2009-11-26  7:06             ` Benjamin Herrenschmidt
2009-11-26  7:06               ` Benjamin Herrenschmidt
2009-11-26  7:06               ` Benjamin Herrenschmidt
2009-11-26  7:52               ` Mitch Bradley
2009-11-26  7:52                 ` Mitch Bradley
2009-11-26  7:52                 ` Mitch Bradley
2009-11-24  8:18 ` [PATCH 05/11] of/flattree: merge early_init_dt_scan_chosen() Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-24  8:18   ` Grant Likely
2009-11-24  8:19 ` [PATCH 06/11] of/flattree: merge early_init_devtree() and early_init_move_devtree() Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-24  8:19   ` [PATCH 06/11] of/flattree: merge early_init_devtree() and Grant Likely
2009-11-26  4:04   ` [PATCH 06/11] of/flattree: merge early_init_devtree() and early_init_move_devtree() Benjamin Herrenschmidt
2009-11-26  4:04     ` Benjamin Herrenschmidt
2009-11-26  4:04     ` [PATCH 06/11] of/flattree: merge early_init_devtree() and Benjamin Herrenschmidt
2009-12-11  6:19     ` [PATCH 06/11] of/flattree: merge early_init_devtree() and early_init_move_devtree() Grant Likely
2009-12-11  6:19       ` Grant Likely
2009-12-11  6:19       ` [PATCH 06/11] of/flattree: merge early_init_devtree() and Grant Likely
2009-12-07  7:08   ` [PATCH 06/11] of/flattree: merge early_init_devtree() and early_init_move_devtree() Jeremy Kerr
2009-12-07  7:08     ` Jeremy Kerr
2009-12-07  7:08     ` Jeremy Kerr
2009-12-11  6:20     ` Grant Likely
2009-12-11  6:20       ` Grant Likely
2009-12-11  6:20       ` [PATCH 06/11] of/flattree: merge early_init_devtree() and Grant Likely
2009-11-24  8:19 ` [PATCH 07/11] of: merge machine_is_compatible() Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-26  4:05   ` Benjamin Herrenschmidt
2009-11-26  4:05     ` Benjamin Herrenschmidt
2009-11-26  4:05     ` Benjamin Herrenschmidt
2009-12-11  6:54     ` Grant Likely
2009-12-11  6:54       ` Grant Likely
2009-12-11  6:54       ` Grant Likely
2009-11-24  8:19 ` [PATCH 08/11] of: Merge of_node_get() and of_node_put() Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-26  4:06   ` Benjamin Herrenschmidt
2009-11-26  4:06     ` Benjamin Herrenschmidt
2009-11-26  4:06     ` Benjamin Herrenschmidt
2009-11-24  8:19 ` [PATCH 09/11] of: merge of_attach_node() & of_detach_node() Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-26  4:07   ` Benjamin Herrenschmidt
2009-11-26  4:07     ` Benjamin Herrenschmidt
2009-11-26  4:07     ` Benjamin Herrenschmidt
2009-12-10 22:21     ` Grant Likely
2009-12-10 22:21       ` Grant Likely
2009-12-10 22:21       ` Grant Likely
2009-11-24  8:19 ` [PATCH 10/11] microblaze: gut implementation of early_init_dt_scan_cpus() Grant Likely
2009-11-24  8:19   ` Grant Likely
2009-11-24  8:19   ` [PATCH 10/11] microblaze: gut implementation of Grant Likely
2009-11-24  8:20 ` [PATCH 11/11] of: unify phandle name in struct device_node Grant Likely
2009-11-24  8:20   ` Grant Likely
2009-11-24  8:20   ` Grant Likely
2009-11-24 17:37   ` David Miller
2009-11-24 17:37     ` David Miller
2009-11-24 17:37     ` David Miller
2009-11-24 20:33     ` Grant Likely [this message]
2009-11-24 20:33       ` Grant Likely
2009-11-24 20:33       ` Grant Likely
2009-11-24 21:10       ` David Miller
2009-11-24 21:10         ` David Miller
     [not found]     ` <20091124.093732.203692950.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2009-11-24 21:06       ` Benjamin Herrenschmidt
2009-11-24 21:06         ` Benjamin Herrenschmidt
2009-11-24 21:06         ` Benjamin Herrenschmidt
2009-11-24 21:39         ` Grant Likely
2009-11-24 21:39           ` Grant Likely
2009-11-24 21:39           ` Grant Likely
2009-11-26 12:28 ` [PATCH 00/11] Yet another series of OF merge patches Wolfram Sang
2009-11-26 12:28   ` Wolfram Sang
2009-11-26 12:28   ` Wolfram Sang

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=fa686aa40911241233k7c6d428g8f70f00abdd754e8@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=microblaze-uclinux@itee.uq.edu.au \
    --cc=monstr@monstr.eu \
    --cc=sfr@canb.auug.org.au \
    --cc=sparclinux@vger.kernel.org \
    /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.