[lkml]   [2001]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ((struct pci_dev*)dev)->resource[...].start
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 |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.276 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site