All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, sparclinux@vger.kernel.org,
	microblaze-uclinux@itee.uq.edu.au, sfr@canb.auug.org.au,
	davem@davemloft.net, monstr@monstr.eu
Subject: Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
Date: Wed, 25 Nov 2009 21:05:59 -0700	[thread overview]
Message-ID: <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com> (raw)
In-Reply-To: <1259207974.16367.226.camel@pasglop>

On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
>> A cell is firmly established as a u32.  No need to do an ugly typedef
>> to redefine it to cell_t.  Eliminate the unnecessary typedef so that
>> it doesn't have to be added to the of_fdt header file
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>
> I'm not sure about that one. Yes, we do use u32 a lot and cell_t rarely,
> so it would seem logical to switch.... On the other hand, we have that
> pesky endianness issue we have never fully solved. So we need accessors
> to sort that out, which means directly tapping things as u32 * is not a
> good idea if we're going to enforce the use of such accessors.
>
> I believe we should probably just enforce that properties are big endian
> for flat device-trees. In which case we could just use __be32 or on of
> thoes sparse-friendly types. I know x86 people won't like that much and
> to be honest I don't know what 1295 specifies for real OFs but there
> aren't enough real OFs around on LE machines for us to care much about
> it, is there ?

Word from Mitch is the device tree is network byte order.  period.

> The reason I prefer a fixed endianness is that allowing "LE" trees
> becomes really nasty when a number is expressed using multiple cells.
> That brings the question as to whether the two cells need to be flipped
> as well or only the bytes within each cell. And that's the easy bit
> (probably flip the whole thing). What about something like a PCI "reg"
> property which is made of 3 cells, two of them forming a 64-bit address
> and one containing additional data & attributes ? What is flipped and
> where ?

exactly.

> So yes, cell_t might not be the right approach and by far to generic a
> name, but u32 isn't the answer neither.

You're right, it's not, but makes merging less complex, and then I can
refactor properly.

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: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, sparclinux@vger.kernel.org,
	microblaze-uclinux@itee.uq.edu.au, sfr@canb.auug.org.au,
	davem@davemloft.net, monstr@monstr.eu
Subject: Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
Date: Thu, 26 Nov 2009 04:05:59 +0000	[thread overview]
Message-ID: <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com> (raw)
In-Reply-To: <1259207974.16367.226.camel@pasglop>

On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
>> A cell is firmly established as a u32.  No need to do an ugly typedef
>> to redefine it to cell_t.  Eliminate the unnecessary typedef so that
>> it doesn't have to be added to the of_fdt header file
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>
> I'm not sure about that one. Yes, we do use u32 a lot and cell_t rarely,
> so it would seem logical to switch.... On the other hand, we have that
> pesky endianness issue we have never fully solved. So we need accessors
> to sort that out, which means directly tapping things as u32 * is not a
> good idea if we're going to enforce the use of such accessors.
>
> I believe we should probably just enforce that properties are big endian
> for flat device-trees. In which case we could just use __be32 or on of
> thoes sparse-friendly types. I know x86 people won't like that much and
> to be honest I don't know what 1295 specifies for real OFs but there
> aren't enough real OFs around on LE machines for us to care much about
> it, is there ?

Word from Mitch is the device tree is network byte order.  period.

> The reason I prefer a fixed endianness is that allowing "LE" trees
> becomes really nasty when a number is expressed using multiple cells.
> That brings the question as to whether the two cells need to be flipped
> as well or only the bytes within each cell. And that's the easy bit
> (probably flip the whole thing). What about something like a PCI "reg"
> property which is made of 3 cells, two of them forming a 64-bit address
> and one containing additional data & attributes ? What is flipped and
> where ?

exactly.

> So yes, cell_t might not be the right approach and by far to generic a
> name, but u32 isn't the answer neither.

You're right, it's not, but makes merging less complex, and then I can
refactor properly.

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: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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, davem@davemloft.net
Subject: Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
Date: Wed, 25 Nov 2009 21:05:59 -0700	[thread overview]
Message-ID: <fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@mail.gmail.com> (raw)
In-Reply-To: <1259207974.16367.226.camel@pasglop>

On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
>> A cell is firmly established as a u32. =A0No need to do an ugly typedef
>> to redefine it to cell_t. =A0Eliminate the unnecessary typedef so that
>> it doesn't have to be added to the of_fdt header file
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>
> I'm not sure about that one. Yes, we do use u32 a lot and cell_t rarely,
> so it would seem logical to switch.... On the other hand, we have that
> pesky endianness issue we have never fully solved. So we need accessors
> to sort that out, which means directly tapping things as u32 * is not a
> good idea if we're going to enforce the use of such accessors.
>
> I believe we should probably just enforce that properties are big endian
> for flat device-trees. In which case we could just use __be32 or on of
> thoes sparse-friendly types. I know x86 people won't like that much and
> to be honest I don't know what 1295 specifies for real OFs but there
> aren't enough real OFs around on LE machines for us to care much about
> it, is there ?

Word from Mitch is the device tree is network byte order.  period.

> The reason I prefer a fixed endianness is that allowing "LE" trees
> becomes really nasty when a number is expressed using multiple cells.
> That brings the question as to whether the two cells need to be flipped
> as well or only the bytes within each cell. And that's the easy bit
> (probably flip the whole thing). What about something like a PCI "reg"
> property which is made of 3 cells, two of them forming a 64-bit address
> and one containing additional data & attributes ? What is flipped and
> where ?

exactly.

> So yes, cell_t might not be the right approach and by far to generic a
> name, but u32 isn't the answer neither.

You're right, it's not, but makes merging less complex, and then I can
refactor properly.

g.


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

  reply	other threads:[~2009-11-26  4:05 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 [this message]
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
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=fa686aa40911252005o2db85dfk3d9acc61c12ca5e5@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.