All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
Date: Wed, 12 Sep 2007 16:51:25 +0200	[thread overview]
Message-ID: <4cd6407b936b2ce65c11092883e7b8d5@kernel.crashing.org> (raw)
In-Reply-To: <200709121013.51500.arnd@arndb.de>

>>>> +struct ranges_pci {
>>>> +	unsigned int pci_space;
>>>> +	u64 pci_addr;
>>>> +	phys_addr_t phys_addr;
>>>> +	u64 size;
>>>> +} __attribute__((packed));
>>>> +
>>>
>>> This structure definition uses unaligned members because of the
>>> 'packed' attribute. Is that really what you intended?
>>>
>> yes, exactly, because I'm mapping this struct on ranges extracted from
>> the dts instead of juggling with ranges[foo] offsets.
>
> I see. It does however look wrong to me, because you are using a 
> hardcoded
> phys_addr_t type. This breaks when phys_addr has a different size from 
> what
> you expect, e.g. when booting a pure 32 bit kernel on a machine that 
> has
> a 64 bit physical address space.

More generally, you can even have a different size for the "phys_addr"
for different nodes in the same device tree.

You really should look at the #address-cells in this node's parent,
and translate that all the way up to the root node to get a CPU
address.


Segher

  reply	other threads:[~2007-09-13  2:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-11 22:49 [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances Vitaly Bordug
2007-09-11 22:57 ` Arnd Bergmann
2007-09-11 23:56   ` Vitaly Bordug
2007-09-12  8:13     ` Arnd Bergmann
2007-09-12 14:51       ` Segher Boessenkool [this message]
2007-09-12 16:07       ` Vitaly Bordug
2007-09-13  5:11         ` David Gibson
2007-09-18 12:03 ` Valentine Barshak
2007-09-18 14:27   ` Vitaly Bordug
2007-09-18 14:38     ` Valentine Barshak
2007-09-19  0:09       ` Vitaly Bordug
2007-09-18 21:44   ` Benjamin Herrenschmidt
2007-09-18 21:41 ` Benjamin Herrenschmidt
2007-09-18 21:42 ` Benjamin Herrenschmidt

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=4cd6407b936b2ce65c11092883e7b8d5@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=arnd@arndb.de \
    --cc=linuxppc-dev@ozlabs.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.