All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] And yet more PCI fixes for 2.5.70
Date: Wed, 11 Jun 2003 13:46:29 -0400	[thread overview]
Message-ID: <20030611174629.GC31051@gtf.org> (raw)
In-Reply-To: <1055351984.2419.23.camel@dhcp22.swansea.linux.org.uk>

On Wed, Jun 11, 2003 at 06:19:49PM +0100, Alan Cox wrote:
> On Mer, 2003-06-11 at 17:38, Greg KH wrote:
> > So that leaves only this file.  Jeff Garzik and I talked about removing
> > pci_present() as it's not needed, and I think for this one case we can
> > live without it.  Do you want me to make the pci_present() macro earlier
> > in this file, so it's readable again?  I don't want to put it back into
> > pci.h.
> 
> I still think it belongs in pci.h. Its an API and the API makes sense. The

Its an API that doesn't make sense.

99% of the uses can simply be eliminated (in 2.4, too).
They are entirely redundant.

The remaining two cases are really arch-specific checks that were
being done wrong anyway.  Note the history:  the definition morphed
in 2.4 from being "PCI BIOS seems to be present, so we'll assume a
PCI bus is present" to "PCI devices are present."  Neither definition
is correct for the question the remaining two cases want answered:
"Is a PCI bus present?"  Further, the IDE code calculating system
bus speed it should really be calling a PCI callback, not asking "Do
I have a PCI bus?" and making a guess...  a guess which seems wrong
in several cases, including my Dual Athlon box w/ 100% 66 Mhz PCI bus.

So, I conclude that pci_present() is wrong for all cases except one --
and that case is sparc64-specific and can be handled with arch-specific
code, I bet.

	Jeff




  reply	other threads:[~2003-06-11 17:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-11  0:11 [BK PATCH] And yet more PCI fixes for 2.5.70 Greg KH
2003-06-11  0:11 ` [PATCH] " Greg KH
2003-06-11  0:11   ` Greg KH
2003-06-11  0:11     ` Greg KH
2003-06-11  0:11       ` Greg KH
2003-06-11 12:37   ` Alan Cox
2003-06-11 12:47     ` Christoph Hellwig
2003-06-11 12:53     ` Dave Jones
2003-06-11 16:38     ` Greg KH
2003-06-11 17:19       ` Alan Cox
2003-06-11 17:46         ` Jeff Garzik [this message]
2003-06-11 19:13           ` Alan Cox

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=20030611174629.GC31051@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.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 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.