From: Grant Grundler <grundler@parisc-linux.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Grant Grundler <grundler@parisc-linux.org>,
Kenji Kaneshige <kaneshige.kenji@soft.fujitsu.com>,
Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pci@atrey.karlin.mff.cuni.cz, Andi Kleen <ak@suse.de>,
benh@kernel.crashing.org,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Subject: Re: [PATCH 0/4] PCI legacy I/O port free driver (take 3)
Date: Mon, 27 Feb 2006 16:28:41 -0700 [thread overview]
Message-ID: <20060227232841.GB9008@colo.lackof.org> (raw)
In-Reply-To: <44037BC6.30003@pobox.com>
On Mon, Feb 27, 2006 at 05:23:02PM -0500, Jeff Garzik wrote:
> Grant Grundler wrote:
> >On Mon, Feb 27, 2006 at 12:43:09PM -0500, Jeff Garzik wrote:
> >
> >>This series still leaves a lot to be desired, and creates unnecessary
> >>driver churn.
> >
> >
> >This is a pretty small change and is not necessary for every driver.
>
> The latter is decidedly false. The change makes no sense at all unless
> you update every conceivable driver that will be used on the target
> platform. You will always be patching drivers as users stick new cards
> in the target hardware.
It's sufficiently true if 90% of the cards plugged into the machine
are covered by 3 or 4 drivers. The remaining 10% can use IO port space
and everything will work fine.
> >If in #1 pci_enable_device() assigns I/O Port resources even though
> >the driver doesn't need it, PCI devices which _only_ support I/O Port
> >space will get screwed (depending on config). We are trying to avoid that.
> >Or do you have another way of avoiding unused resource allocation?
>
> Fix the [firmware | device load order] to allocate I/O ports first to
> the hardware that only supports IO port accesses. Problem solved with
> zero kernel mods...
After we (OS developers) have been telling firmware people to NOT
configure every device and run it's BIOS driver at power up?
OS "hotplug" now deals with resource assignment and device initialization
in most cases on these boxes. Running the BIOS/EFI driver to configure
each device just takes too long.
grant
next prev parent reply other threads:[~2006-02-27 23:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 4:50 Kenji Kaneshige
2006-02-27 4:52 ` [PATCH 1/4] PCI legacy I/O port free driver (take 3) - Add no_ioport flag into pci_dev Kenji Kaneshige
2006-02-27 4:52 ` [PATCH 2/4] PCI legacy I/O port free driver (take 3) - Update Documentation/pci.txt Kenji Kaneshige
2006-02-27 6:53 ` Grant Grundler
2006-02-27 8:27 ` Kenji Kaneshige
2006-02-27 12:18 ` Kenji Kaneshige
2006-02-27 12:27 ` Kenji Kaneshige
2006-02-27 4:53 ` [PATCH 3/4] PCI legacy I/O port free driver (take 3) - Make Intel e1000 driver legacy I/O port free Kenji Kaneshige
2006-02-27 4:54 ` [PATCH 4/4] PCI legacy I/O port free driver (take 3) - Make Emulex lpfc " Kenji Kaneshige
2006-02-27 17:43 ` [PATCH 0/4] PCI legacy I/O port free driver (take 3) Jeff Garzik
2006-02-27 21:42 ` Grant Grundler
2006-02-27 22:23 ` Jeff Garzik
2006-02-27 22:42 ` Andi Kleen
2006-02-27 22:52 ` Jeff Garzik
2006-02-27 22:58 ` Andi Kleen
2006-02-27 23:28 ` Grant Grundler [this message]
2006-02-28 2:59 ` Kenji Kaneshige
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=20060227232841.GB9008@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=kaneshige.kenji@soft.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/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
all inboxes | Powered by JetHome®