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 15:20:43 -0700	[thread overview]
Message-ID: <20021026152043.A13850@lucon.org> (raw)
In-Reply-To: <3DBB1150.2030800@pobox.com>; from jgarzik@pobox.com on Sat, Oct 26, 2002 at 06:04:00PM -0400

On Sat, Oct 26, 2002 at 06:04:00PM -0400, Jeff Garzik wrote:
> Which is the entire problem.  The kernel compiles and builds just fine 
> right now, without your function.
> 

Without my patch or my function? My patched file has

        if ((pci_probe & PCI_BUS_SORT) && !(pci_probe & PCI_NO_SORT))
                pci_sort_by_bus_slot_func();
#ifdef CONFIG_PCI_BIOS
        else if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
                pcibios_sort();
#endif

That is pci_sort_by_bus_slot_func () will be called if PCI_BUS_SORT is
set. It is independent of whether CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is
set or not, which sets PCI_BUS_SORT. If pci_sort_by_bus_slot_func is
not defined when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set. How can
kernel compile?

> If it is "just not called by default" then it clearly can be removed at 
> compile time when a certain CONFIG_xxx is not defined.

It is controlled by PCI_BUS_SORT, not CONFIG_xxx.

> 
> 
> >>>>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.
> >  
> >
> 
> Sigh.  Repeating, the kernel is still bloated by your sorting function 
> if CONFIG_PCI_SORT_BY_BUS_SLOT is not defined.  The function should go 
> away if CONFIG_PCI_SORT_BY_BUS_SLOT is not defined.

I added pci=nobussort since it might not be safe for all MBs. Then I
added "pci=bussort". I have no problem taking out "pci=bussort". If you
don't want "pci=bussort", please say so. I can provide a new patch which
won't define pci_sort_by_bus_slot_func if CONFIG_PCI_SORT_BY_BUS_SLOT
is not set and won't have "pci=bussort" either.


H.J.

  reply	other threads:[~2002-10-26 22:14 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
2002-10-26 22:04                   ` Jeff Garzik
2002-10-26 22:20                     ` H. J. Lu [this message]
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=20021026152043.A13850@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.