From: James L Peterson <peterson@austin.ibm.com>
To: paulus@samba.org
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: Mon, 22 Apr 2002 09:14:31 -0500 [thread overview]
Message-ID: <3CC41AC6.BD8E32E4@austin.ibm.com> (raw)
In-Reply-To: <OF8A238806.80D1511C-ON87256B75.00773B75@boulder.ibm.com> <20020307220318.GA4664@haven> <3CC08DFF.787F6E54@austin.ibm.com> <20020419.143839.15920500.davem@redhat.com> <15553.12447.849592.261245@argo.ozlabs.ibm.com>
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.
Specifically:
Little-endian dword:
3 2 1 0
80 86 71 11
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.
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).
jim
Contrast this with replacing the read_config_dword with
reading two words:
Instead of:
if (pci_read_config_dword(temp, PCI_VENDOR_ID, &l))
return NULL;
....
memcpy(dev, temp, sizeof(*dev));
dev->vendor = l & 0xffff;
dev->device = (l >> 16) & 0xffff;
It would seem that we need:
if (pci_read_config_word(temp, PCI_VENDOR_ID, &vendor))
return NULL;
if (pci_read_config_word(temp, PCI_DEVICE_ID, &device))
return NULL;
Paul Mackerras wrote:
> David S. Miller writes:
>
> > From: James L Peterson <peterson@austin.ibm.com>
> > Date: Fri, 19 Apr 2002 16:37:03 -0500
> >
> > if (pci_read_config_dword(temp, PCI_VENDOR_ID, &l))
> > return NULL;
> > ....
> > memcpy(dev, temp, sizeof(*dev));
> > dev->vendor = l & 0xffff;
> > dev->device = (l >> 16) & 0xffff;
> >
> > It seems to me this is incorrect for a big-endian machine
> > (like PowerPC). If we read the two 16-bit parts out of the
> > first 32-bit part, we will end up with:
> >
> > pci_read_config_dword should do the byte swapping on &l for
> > the caller, fix your pci_{read,write}_config_*() arch implementation.
>
> It does, that's why it all works. :) James Peterson seems to have
> missed this fact, hence his confusion.
>
> Paul.
next prev parent reply other threads:[~2002-04-22 14:23 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 ` PowerPC Linux and PCI 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 [this message]
2002-04-23 8:00 ` Paul Mackerras
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
-- strict thread matches above, loose matches on Subject: below --
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=3CC41AC6.BD8E32E4@austin.ibm.com \
--to=peterson@austin.ibm.com \
--cc=anton@au.ibm.com \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@suse.cz \
--cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox