On Tue, Jun 30, 2015 at 03:57:16PM -0700, Dan Williams wrote: > > void __iomem *ioremap_flags(resource_size_t offset, unsigned long size, > > unsigned long prot_val, unsigned flags); > > Doesn't 'flags' imply a specific 'prot_val'?
Looks like the values are arch specific. So as a first step I'd like to keep them separate. As a second step we could look into unifying the actual ioremap implementations which look mostly the same. Once that is done we could look into collapsing the flags and prot_val arguments. > One useful feature of the ifdef mess as implemented in the patch is > that you could test for whether ioremap_cache() is actually > implemented or falls back to default ioremap(). I think for > completeness archs should publish an ioremap type capabilities mask > for drivers that care... (I can imagine pmem caring), or default to > being permissive if something like IOREMAP_STRICT is not set. There's > also the wrinkle of archs that can only support certain types of > mappings at a given alignment. I think doing this at runtime might be a better idea. E.g. a ioremap_flags with the CACHED argument will return -EOPNOTSUP unless actually implemented. On various architectures different CPUs or boards will have different capabilities in this area. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
