All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
Date: Sat, 26 Oct 2002 14:44:41 -0700	[thread overview]
Message-ID: <20021026144441.A13479@lucon.org> (raw)
In-Reply-To: <3DBB0A81.6060909@pobox.com>; from jgarzik@pobox.com on Sat, Oct 26, 2002 at 05:34:57PM -0400

On Sat, Oct 26, 2002 at 05:34:57PM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:
> 
> >On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
> >  
> >
> >>Well, WRT your implementation, the function you add is dead code if your 
> >>new config variable is not set, which is not desireable at all.
> >>    
> >>
> >
> >I am not sure if I understand what you were trying to say. If
> >CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to 
> >pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
> >function. Did I miss something?
> >  
> >
> The sorting function you add should be covered by the ifdef you add.

Have you tried? If I did that, the kernel wouldn't even compile. As I
said, when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC isn't defined, my sorting
function is still available, just not called by default.

> 
> >>WRT the overall idea, I would prefer to see what Linus and Martin Mares 
> >>(and Ivan K) thought about it, before merging it.  The x86 PCI code is 
> >>very touchy, and your patch has the potential to change driver probe 
> >>order for little gain.
> >>
> >>    
> >>
> >
> >The whole purpose of my patch is to change PCI driver probe order in
> >such a way that is BIOS independent.
> >  
> >
> 
> The purpose is irrelevant to the effect on existing drivers and systems 
> -- which is unknown.  Making the probe order independent of BIOS 
> ordering may very well break drivers and systems that are dependent on 
> BIOS ordering.  IOW what looks nice on your system could _likely_ suck 
> for others.  That's what I meant by "x86 PCI code is very touchy."

That is why CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is off by default and
even if it is on, you can still override it by passing "pci=nosort"
or "pci=nobussort" to kernel.



H.J.

  reply	other threads:[~2002-10-26 21:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-24 23:39 PCI device order problem H. J. Lu
2002-10-24 23:49 ` Jeff Garzik
2002-10-24 23:56   ` H. J. Lu
2002-10-25  0:14     ` Jeff Garzik
2002-10-25  0:18       ` H. J. Lu
2002-10-25 10:00     ` Alan Cox
2002-10-25 16:11       ` H. J. Lu
2002-10-26  3:26         ` PATCH: Support PCI device sorting (Re: PCI device order problem) H. J. Lu
2002-10-26 21:12           ` Jeff Garzik
2002-10-26 21:27             ` H. J. Lu
2002-10-26 21:34               ` Jeff Garzik
2002-10-26 21:44                 ` H. J. Lu [this message]
2002-10-26 22:04                   ` Jeff Garzik
2002-10-26 22:20                     ` H. J. Lu
2002-10-26 22:29                       ` Jeff Garzik
2002-10-26 22:53                         ` H. J. Lu
2002-10-26 22:58                           ` Jeff Garzik
2002-10-26 23:45                             ` Alan Cox
2002-10-26 23:53                             ` H. J. Lu
2002-10-26 23:57                               ` Jeff Garzik
2002-10-27  0:05                                 ` Jeff Garzik
2002-10-27  0:25                                   ` H. J. Lu
2002-10-27 17:42                                     ` Greg KH
2002-10-27 20:42                                       ` H. J. Lu
2002-10-28  0:26                                         ` Jeff Garzik
2002-10-27  0:30                                   ` 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=20021026144441.A13479@lucon.org \
    --to=hjl@lucon.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jgarzik@pobox.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.