Arnd Bergmann wrote: > On Saturday 09 May 2009, Benjamin Herrenschmidt wrote: > >> This was shot down by a vast majority of people, with the outcome being >> an agreement that for IORESOURCE_MEM, pci_iomap and friends must return >> something that is strictly interchangeable with what ioremap would have >> returned. >> >> That means that readl and writel must work on the output of pci_iomap() >> and similar, but I don't see why __raw_writel would be excluded there, I >> think it's in there too. >> > > One of the ideas was to change pci_iomap to return a special token > in case of virtual devices that causes iowrite32() to do an hcall, > and to just define writel() to do iowrite32(). > > Unfortunately, there is no __raw_iowrite32(), although I guess we > could add this generically if necessary. > > >> Direct dereference is illegal in all cases though. >> > > right. > > >> The token returned by pci_iomap for other type of resources (IO for >> example) is also only supported for use by iomap access functions >> (ioreadXX/iowriteXX) , and IO ports cannot be passed directly to those >> neither. >> > > That still leaves the option to let drivers pass the IORESOURCE_PVIO > for its own resources under some conditions, meaning that we will > only use hcalls for I/O on these drivers but not on others, as Chris > explained earlier. > Between this, and Avi's "nesting" point, this is the direction I am leaning in right now. -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
