linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexandros Kostopoulos <akostop@inaccessnetworks.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: pci in arch/powerpc vs arch/ppc
Date: Thu, 09 Aug 2007 08:55:47 +1000	[thread overview]
Message-ID: <1186613748.938.205.camel@localhost.localdomain> (raw)
In-Reply-To: <op.twqvg3i0nhx3hy@phoenix>

On Wed, 2007-08-08 at 17:21 +0300, Alexandros Kostopoulos wrote:
> I've noticed the following: In function pci_process_bridge_OF_ranges, when  
> parsing the ranges for MEM and I/O space, the res->start for mem is  
> correctly set to ranges[na+2], which is the cpu address in the ranges  
> property. However, in I/O related code, res->start is set to ranges[2],  
> which is in the PCI address field of the ranges property (and in my case  
> is 0, as is also for the mpc8272ads case as well). Thus, the res->start of  
> the I/O of the bridge is 0, which leads to the first device with I/O space  
> (a davicom ethernet device) been also assigned a I/O region starting at 0.  
> Finally, the dmfe (davicom ethernet driver over PCI) fails with "dmfe: I/O  
> base is zero". So, is the implementation of pci_process_bridge_OF_ranges  
> correct ? shouldn't res->start = ranges[na+2] for I/O as well?

The current code indeed assumes that IO space of a PCI host bridges starts
at 0 local always. We "fixed" that in the 64 bits variant but not the 32 bits
one (yet...).

Note that if we're going to fix it, we probably also need to change various
bits of resource fixup code as well that makes that assumption.

Might be worth trying making more of that stuff common between 32 and 64
bits (I hear the noise of people trying to get me merge the pci code .. :-)

Ben.

  parent reply	other threads:[~2007-08-08 22:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-03 14:58 pci in arch/powerpc vs arch/ppc Alexandros Kostopoulos
2007-08-03 20:10 ` Scott Wood
2007-08-04 16:39   ` Kumar Gala
2007-08-07  9:06     ` Alexandros Kostopoulos
2007-08-07 15:20       ` Scott Wood
2007-08-08 11:42         ` Alexandros Kostopoulos
2007-08-08 13:03           ` Alexandros Kostopoulos
2007-08-08 16:24             ` Scott Wood
2007-08-08 14:21           ` Alexandros Kostopoulos
2007-08-08 19:11             ` Scott Wood
2007-08-08 19:46               ` Alexandros Kostopoulos
2007-08-08 19:56                 ` Scott Wood
2007-08-08 22:20                   ` Alexandros Kostopoulos
2007-08-09 15:04                     ` Scott Wood
2007-08-09 15:56                       ` Segher Boessenkool
2007-08-11 23:28                         ` Benjamin Herrenschmidt
2007-08-10  4:32                 ` Paul Mackerras
2007-08-08 22:55             ` Benjamin Herrenschmidt [this message]
2007-08-08 16:29           ` MPC8260 PCI9 erratum Scott Wood

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=1186613748.938.205.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akostop@inaccessnetworks.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).