From: Jeff Garzik <jgarzik@pobox.com>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: 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 17:23:02 -0500 [thread overview]
Message-ID: <44037BC6.30003@pobox.com> (raw)
In-Reply-To: <20060227214244.GA9008@colo.lackof.org>
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.
>> The better solution is:
>>
>>1) pci_enable_device() enables what it can
>>
>>2) Drivers, as they already do, will fail if they cannot map the desired
>>memory or IO resources that are needed.
>>
>>Thus, the PCI layer needs only to do #1, and existing driver code
>>handles the rest of the situation as one currently expects.
>
>
> 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...
Jeff
next prev parent reply other threads:[~2006-02-27 22:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 4:50 [PATCH 0/4] PCI legacy I/O port free driver (take 3) 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 [this message]
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
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=44037BC6.30003@pobox.com \
--to=jgarzik@pobox.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=grundler@parisc-linux.org \
--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 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.