All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Kenji Kaneshige <kaneshige.kenji@soft.fujitsu.com>,
	Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>
Cc: 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 12:43:09 -0500	[thread overview]
Message-ID: <44033A2D.9000902@pobox.com> (raw)
In-Reply-To: <44028502.4000108@soft.fujitsu.com>

Kenji Kaneshige wrote:
> Hi,
> 
> Here is an updated set of patches for PCI legacy I/O port free drivers
> which incorporates feedbacks. Summary of changes from the previous
> version are:
> 
>     - Removed the device_flags field from struct pci_device_id, which
>       was introduced in the previous version of patch
> 
>     - Changed e1000 driver to use the driver_data field in struct
>       pci_device_id to see if the device needs I/O port regions.
> 
>     - Added proper messages instead of WARN_ON() at the error.
> 
>     - Updated the Documentation/pci.txt
> 
> I'm attaching the following four patches:
> 
>     [patch 1/4] Add no_ioport flag into pci_dev
>     [patch 2/4] Update Documentation/pci.txt
>     [patch 3/4] Make Intel e1000 driver legacy I/O port free
>     [patch 4/4] Make Emulex lpfc driver legacy I/O port free
> 
> I'm attaching the brief description below about what the problem I'm
> trying to solve is.
> 
> Thanks,
> Kenji Kaneshige
> 
> 
> Brief Description
> ~~~~~~~~~~~~~~~~~
> I encountered a problem that some PCI devices don't work on my system
> which have huge number of PCI devices.
> 
> It is mandatory for all PCI device drivers to enable the device by
> calling pci_enable_device() which enables all regions probed from the
> device's BARs. If pci_enable_device() failes to enable any regions
> probed from BARs, it returns as error. On the large servers, I/O port
> resource could not be assigned to all PCI devices because it is
> limited (64KB on Intel Architecture[1]) and it would be fragmented
> (I/O base register of PCI-to-PCI bridge will usually be aligned to a
> 4KB boundary[2]). In this case, the devices which have no I/O port
> resource assigned don't work because pci_enable_device() for those
> devices failes. This is what happened on my machine.

This series still leaves a lot to be desired, and creates unnecessary
driver churn.  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.

	Jeff



  parent reply	other threads:[~2006-02-27 17:43 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 ` Jeff Garzik [this message]
2006-02-27 21:42   ` [PATCH 0/4] PCI legacy I/O port free driver (take 3) 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
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=44033A2D.9000902@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=benh@kernel.crashing.org \
    --cc=greg@kroah.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 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.