From: Greg KH <greg@kroah.com>
To: "Grover, Andrew" <andrew.grover@intel.com>
Cc: "Lee, Jung-Ik" <jung-ik.lee@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: bare pci configuration access functions ?
Date: Thu, 31 Oct 2002 13:23:49 -0800 [thread overview]
Message-ID: <20021031212349.GA10689@kroah.com> (raw)
In-Reply-To: <EDC461A30AC4D511ADE10002A5072CAD04C7A492@orsmsx119.jf.intel.com>
On Thu, Oct 31, 2002 at 01:07:08PM -0800, Grover, Andrew wrote:
> > From: Lee, Jung-Ik [mailto:jung-ik.lee@intel.com]
> > Some kernel drivers/components such as hotplug
> > pci/io-node drivers,
> > ACPI driver, some console drivers, etc **need bare pci
> > configuration space
> > access** before either pci driver is initialized or struct pci_dev is
> > constructed.
> >
> > ACPI needs this for ACPI/PCI population, hotplug pci driver
> > for populating
> > hot-added pci hierarchy. As more drivers are cross ported
> > over to wider
> > architectures, this would become wider need. Help me if
> > others need this
> > too.
>
> When the PCI Config stuff got revamped a few months ago, Greg KH, myself,
> and some other people discussed this, and the conclusion seemed to be that
> it was less ugly to make the code that needs bare PCI config access use fake
> structs, than to have the bare functions exposed. Greg, am I remembering
> correctly?
No. Well, I don't think so anyway. In 2.5 we now have a pci_bus_read_*
and pci_bus_write_* functions, which the pci hotplug drivers use, as
they at least know the bus on which the devices they are looking for are
on. I also had to convert over some ACPI code that was using the
pci_read_config functions to get everything to work properly, but I
don't seem to be able to find that code in the latest 2.5 tree, so I
guess you don't need to do that anymore?
(For the LKML readers, this is a spill-over from the pci hotplug and
ia64 mailing lists, where on 2.4 we now have a problem with pci hotplug
drivers as ia64 uses a pci "segment" and the existing pci_*_nodev
functions in the pci hotplug core don't properly set up this field. See
the archives for either of those lists for more info.)
thanks,
greg k-h
next prev parent reply other threads:[~2002-10-31 21:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-31 21:07 bare pci configuration access functions ? Grover, Andrew
2002-10-31 21:23 ` Greg KH [this message]
2002-10-31 23:40 ` Kai Germaschewski
-- strict thread matches above, loose matches on Subject: below --
2002-10-31 22:00 Grover, Andrew
2002-10-31 22:11 ` Greg KH
2002-10-31 22:50 ` Scott Murray
2002-10-31 23:46 ` Greg KH
2002-11-01 0:23 ` Scott Murray
2002-10-31 23:37 ` KOCHI, Takayoshi
2002-10-31 23:54 ` Greg KH
2002-11-01 0:23 ` KOCHI, Takayoshi
2002-11-01 1:13 ` Greg KH
2002-11-01 2:07 Grover, Andrew
2002-11-01 2:45 ` Greg KH
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=20021031212349.GA10689@kroah.com \
--to=greg@kroah.com \
--cc=andrew.grover@intel.com \
--cc=jung-ik.lee@intel.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.