All of lore.kernel.org
 help / color / mirror / Atom feed
From: James L Peterson <peterson@austin.ibm.com>
To: Anton Blanchard <anton@au.ibm.com>, paulus@ozlabs.au.ibm.com
Cc: mj@suse.cz, linux-kernel@vger.kernel.org
Subject: PowerPC Linux and PCI
Date: Fri, 19 Apr 2002 16:37:03 -0500	[thread overview]
Message-ID: <3CC08DFF.787F6E54@austin.ibm.com> (raw)
In-Reply-To: <OF8A238806.80D1511C-ON87256B75.00773B75@boulder.ibm.com> <20020307220318.GA4664@haven>

I apologize if this message is directed incorrectly; any hints you could
give on who else to ask on this would be appreciated.

I'm trying to get Linux running on a 405GP system with PCI.  Actually
it's on the mambo simulator and I'm writing the PCI support.  My
information about PCI comes from the PCI System Architecture
book by MindShare; also the PPC405GP User's Manual. My problem is
basically a big-endian/little-endian problem.  All of the documents
agree that the Vendor ID is in bytes 0 and 1, and the Device ID
is in bytes 2 and 3.  The header file include/linux/pci.h agrees:

#define PCI_VENDOR_ID  0x00 /* 16 bits */
#define PCI_DEVICE_ID  0x02 /* 16 bits */

But in drivers/pci/pci.c, when we are trying to discover
a particular device, in pci_scan_device, the code
reads out a dword (a 32-bit quantity) and then masks
out the two subfields:

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:

        0       1            2        3
        vendor-id       device-id

with a big-endian machine, but

       0        1           2         3
      device-id         vendor-id

for a little endian machine.  This would make the mask and
shift definition to the vendor and device field correct for little
endian, but swapped for big-endian.

There is a similar problem for the read of the Class Code
and Revision ID dword in pci_setup_device, where, again,
they read the dword and then shift to get the "upper 3  bytes"
while on a big-endian machine, you would actually want the
"lower 3 bytes" for the 3-byte Class Code field.

The fixes to this code is fairly simple -- always read the size
of field that is defined from the bytes where it is defined to be --
but I am more confused by why this has not shown up before.
This seems a fundamental problem -- incorrectly defining the
device and vendor fields for a PCI device -- which would have
prevented PCI devices from working on PowerPC systems
(or any other big-endian system), but I don't see #ifdef's for
it, or platform-specific code to correct it or anything else.
Yet since these fields are defined by hardware manufacturers,
I would expect they are always as defined by the PCI document,
that is always little-endian.  So it seems that the code can't work,
and yet ...

I'd appreciate any comments or recommendations.

jim

James Peterson
IBM Austin Research Lab
Austin, Texas



       reply	other threads:[~2002-04-19 21:43 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 [this message]
2002-04-19 21:38     ` PowerPC Linux and PCI 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
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=3CC08DFF.787F6E54@austin.ibm.com \
    --to=peterson@austin.ibm.com \
    --cc=anton@au.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mj@suse.cz \
    --cc=paulus@ozlabs.au.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 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.