From: Paul Mackerras <paulus@samba.org>
To: James L Peterson <peterson@austin.ibm.com>
Cc: "David S. Miller" <davem@redhat.com>,
anton@au.ibm.com, mj@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: PowerPC Linux and PCI
Date: Tue, 23 Apr 2002 18:00:47 +1000 (EST) [thread overview]
Message-ID: <15557.5295.921549.964163@argo.ozlabs.ibm.com> (raw)
In-Reply-To: <3CC41AC6.BD8E32E4@austin.ibm.com>
James L Peterson writes:
> I haven't overlooked the fact that the pci_read_config_dword will
> do the byte swapping. But it will do the byte_swapping for a
> dword (32-bits), not for two words (16-bits), and the byte-swapping
> for 32-bits is not the same as for two words.
The host bridge should preserve the byte numbering, i.e. byte address
0 on the host side should access byte 0 on the PCI side, not byte 3.
In your example:
> Specifically:
>
> Little-endian dword:
>
> 3 2 1 0
> 80 86 71 11
So we have byte[0] = 0x11, byte[1] = 0x71, byte[2] = 86, byte[3] =
0x80, right? If we read individual bytes we will get the same results
on a little-endian or a big-endian platform.
> when read in by the pci_read_config_dword, will swap it to :
>
> 0 1 2 3
> 11 71 86 80
>
> For little endian you get device id (bytes 2,3) as 0x8086,
> and vendor id of 0x7111. For big endian you get device
> id of 0x7111 and vendor id of 0x8086.
On a little endian platform, pci_read_config_dword will return
0x80867111, since byte 0 is the least-significant byte. Thus we have
vendor id = 0x7111 and device-id = 0x8086.
On a big-endian platform a 32-bit read will return 0x11718680 (since
byte 0 is the most significant byte), and pci_read_config_dword will
byte-swap that to 0x80867111. Thus we once again have vendor id =
0x7111 and device-id = 0x8086.
> The pci_read_config_dword works just fine for dword
> data types, like the base addresses. But the fundamental
> rule of big-endian/little-endian code is that you have to
> know the size of the data type that you are working with,
> so that you can byte swap properly. Reading a dword
> (and byte-swapping for a dword) is not the same as
> reading two words (and byte-swapping them as words).
You do in fact get the same effect because of the invariance of the
individual byte addresses.
Doesn't the fact that people have been successfully using PCI devices
in PowerPC machines since 1995 or 1996 suggest to you that it might be
your understanding that is faulty rather than the code? :)
Paul.
next prev parent reply other threads:[~2002-04-23 8:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OF8A238806.80D1511C-ON87256B75.00773B75@boulder.ibm.com>
[not found] ` <20020307220318.GA4664@haven>
2002-04-19 21:37 ` James L Peterson
2002-04-19 21:38 ` David S. Miller
2002-04-20 9:10 ` Paul Mackerras
2002-04-22 14:14 ` James L Peterson
2002-04-23 8:00 ` Paul Mackerras [this message]
2002-04-23 8:14 ` David S. Miller
2002-04-23 16:54 ` James L Peterson
2002-04-23 17:53 ` James L Peterson
2002-04-23 17:16 Ed Vance
2002-04-24 3:59 ` David S. Miller
2002-04-24 16:45 Ed Vance
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=15557.5295.921549.964163@argo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=anton@au.ibm.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@suse.cz \
--cc=peterson@austin.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
all inboxes | Powered by JetHome®