From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Jonathan Lundell <jlundell@pobox.com>
Cc: "Khachaturov, Vassilii" <Vassilii.Khachaturov@comverse.com>,
LINUX Kernel <linux-kernel@vger.kernel.org>
Subject: Re: ((struct pci_dev*)dev)->resource[...].start
Date: Wed, 16 May 2001 19:14:19 -0400 [thread overview]
Message-ID: <3B0309CB.1346D25F@mandrakesoft.com> (raw)
In-Reply-To: <6B1DF6EEBA51D31182F200902740436802678ED4@mail-in.comverse-in.com> <3B02F30F.5D05C77E@mandrakesoft.com> <p05100306b728b73efd94@[10.128.7.49]>
Jonathan Lundell wrote:
>
> At 5:37 PM -0400 2001-05-16, Jeff Garzik wrote:
> >This is not a safe assumption, because the OS may reprogram the PCI BARs
> >at certain times. The rule is: ALWAYS read from dev->resource[] unless
> >you are a bus driver (PCI bridges, for example, need to assign
> >resources).
>
> Would you please elaborate? If I understand what you're saying, you
> can't rely on the "pointer" returned by ioremap() because the OS
> might reprogram the relevant BAR out from under you. So one would
> need to know: when does a driver have to re-ioremap() due to the BAR
> having been (potentially) changed? I'd expect the answer to be: for
> all practical purposes never.
no-no-no. I DON'T mean that OS will reprogram the BARs underneath you.
Only that it is the responsibility of the OS to program the BARs, and
that you should be getting the BAR info out of dev->resource[].
Note only does this make the code much cleaner, but this gives us a lot
more flexibility about when and how we program the PCI bus. The PCI
driver only needs to know the location and size of the region it needs
to access. If the OS, in the future, has to support some weird IOMMU or
PCI mapping capabilities, we don't have to go through and change all the
drivers which are suddenly broken by this new hardware... we just change
it in one canonical place: the PCI core. (at this point the lecture
turns into why APIs exist and should be used, and it gets more boring
from there...)
--
Jeff Garzik | Game called on account of naked chick
Building 1024 |
MandrakeSoft |
next prev parent reply other threads:[~2001-05-16 23:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-16 20:58 ((struct pci_dev*)dev)->resource[...].start Khachaturov, Vassilii
2001-05-16 21:37 ` Jeff Garzik
2001-05-16 23:06 ` Jonathan Lundell
2001-05-16 23:14 ` Jeff Garzik [this message]
2001-05-17 5:36 ` Albert D. Cahalan
-- strict thread matches above, loose matches on Subject: below --
2001-05-16 22:13 Khachaturov, Vassilii
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=3B0309CB.1346D25F@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=Vassilii.Khachaturov@comverse.com \
--cc=jlundell@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.