public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: anton@samba.org
To: Tom Gall <tom_gall@vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RFC: Changes for PCI
Date: Thu, 28 Jun 2001 09:12:48 +1000	[thread overview]
Message-ID: <20010628091248.A23627@krispykreme> (raw)
In-Reply-To: <3B3A58FC.2728DAFF@vnet.ibm.com>
In-Reply-To: <3B3A58FC.2728DAFF@vnet.ibm.com>


Hi,

> The following 3 functions are added. Their purpose is a little
> different than to add support for more than 256 buses but they are
> important. Skip ahead and I'll explain what they are for....
> 
> int (*pci_read_bases)(struct pci_dev *, int cnt,int rom);  /* These optional
> hooks provide */
> int (*pci_read_irq)(struct pci_dev *);                     /* the arch dependant
> code a way*/
> int (*pci_fixup_registers)(struct pci_dev *);              /* to manage the
> registers.     */

I do not think these functions are required at all.

> The 3 additional functions are hooks so that an architecture has a
> chance to make sure things are in order beforehand. pci_read_bases is
> for the management and fixup of the BARs. pci_read_irq is the same but
> for IRQs.  pci_fixup_registers again same idea but for bridge
> resources.
> 
> The essense of the design here is to allow you to get in and make sure
> everything is ok with the card, bridge etc, beforehand so as to avoid
> multiple bus walks. 

Please look at how other architectures solve this problem. For example
on ppc32 we already fix up the BARs if required. There are also hooks
to fix the irq, you seem to be duplicating all of this.

Anton

  parent reply	other threads:[~2001-06-27 23:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-27 22:06 RFC: Changes for PCI Tom Gall
2001-06-27 22:15 ` Jeff Garzik
2001-06-27 22:57   ` Tom Gall
2001-06-27 23:34     ` Jeff Garzik
2001-06-27 18:24       ` Tom Gall
2001-06-28 20:57       ` Gérard Roudier
2001-06-28 21:11         ` Tom Gall
2001-06-28 21:18           ` Jeff Garzik
2001-06-28 21:12         ` Jeff Garzik
2001-06-28  1:02     ` David S. Miller
2001-06-27 19:07       ` Tom Gall
2001-06-29  5:22         ` Richard Henderson
2001-06-29  3:14           ` Tom Gall
2001-06-27 23:17   ` anton
2001-06-28  1:04     ` David S. Miller
2001-06-27 18:49       ` Tom Gall
2001-06-28  4:06         ` David S. Miller
2001-06-27 20:01           ` Tom Gall
     [not found]   ` <mailman.993682861.9307.linux-kernel2news@redhat.com>
2001-06-27 23:41     ` Pete Zaitcev
2001-06-28  0:48       ` David S. Miller
2001-06-28  1:00   ` David S. Miller
2001-06-27 23:12 ` anton [this message]
2001-06-28  0:59 ` David S. Miller
2001-06-28 16:48   ` Todd Inglett
2001-06-28 17:01     ` Jeff Garzik
2001-06-28 17:20       ` Todd Inglett
2001-06-28 17:01     ` Alan Cox
2001-06-28 21:54       ` Gérard Roudier
  -- strict thread matches above, loose matches on Subject: below --
2001-06-28 23:08 Khachaturov, Vassilii
2001-06-28 23:27 ` Jeff Garzik

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=20010628091248.A23627@krispykreme \
    --to=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tom_gall@vnet.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