pci rework not quite ready yet?

[Jesse Barnes]

> > Then the address in the BAR is relegated to "cookie" status.  This
> > would be fine, but the code is (or at least used to be) somewhat
> > confused in this regard.  At times the address was used as a 'real'
> > address, resulting in bugs and BAR corruption on various platforms.
> >  Also, the code didn't properly tie a given BAR value to a specific
> > bus or PCI domain, resulting in duplicates and other bugs.  I'd be
> > much happier if we just got away from using bus addresses entirely.
> >  There's really no way we can use them reliably short of growing
> > sophisticated bus drivers in the X server...
>
> And this is a fair portion of the reason I started on pci-rework in
> the first place.  Or did I mention that before?  In some cases just
> getting the bus address of the device is a huge PITA.

Yep, I remember.  But Keith is right that there are some valid uses, I 
just hope we can keep the confusion to a minimum with this new API.

> > Also, adding this new interface seems like a lot of churn for just
> > dealing with cacheability attributes.  Maybe it would be best to
> > have a separate, madvise-like call to set the attributes instead? 
> > The user would be required to pass in a range or subrange already
> > mapped by a previous mapping call. E.g.
> >
> >   error_t pci_device_set_range_attributes(struct pci_device *dev,
> > 					  pciaddr_t offset, size_t size,
> > 					  unsigned flags)
> >
> > This has the added bonus of making error checking easy, e.g. if you
> > try to set WC on a range and it fails, you'll still have the
> > mapping but you can warn the user that it won't be very performant.
>
> I think we want to set the access bits when we do the mapping.  It
> looks like some platforms (IA64) set these bits from flags passed to
> mmap. This is somewhat unfamiliar territory for me, so I may be
> mistaken. Using flags passed to mmap seems like the right way to
> interface with PAT, but that's just my $0.02.

Yeah, using mmap flags makes sense.  We'll have to make sure any PAT 
work uses them if possible.  As for setting the bits when doing the 
mapping, that's fine by me, my only concern is falling back to a less 
desirable attribute will be a little messier if the mapping and 
attribute setting are combined.

Jesse