They are both defined the same way, but this makes it easier to validate the scripted ioremap_nocache removal following soon.
Unified · Split
| @@ -227,29 +227,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t offset, · 226 unmodified lines | ||
| 227 | 227 | */ |
| 228 | 228 | #define ioremap(offset, size) \ |
| 229 | 229 | __ioremap_mode((offset), (size), _CACHE_UNCACHED) |
| 230 | − | |
| 231 | −/* | |
| 232 | − * ioremap_nocache - map bus memory into CPU space | |
| 233 | − * @offset: bus address of the memory | |
| 234 | − * @size: size of the resource to map | |
| 235 | − * | |
| 236 | − * ioremap_nocache performs a platform specific sequence of operations to | |
| 237 | − * make bus memory CPU accessible via the readb/readw/readl/writeb/ | |
| 238 | − * writew/writel functions and the other mmio helpers. The returned | |
| 239 | − * address is not guaranteed to be usable directly as a virtual | |
| 240 | − * address. | |
| 241 | − * | |
| 242 | − * This version of ioremap ensures that the memory is marked uncachable | |
| 243 | − * on the CPU as well as honouring existing caching rules from things like | |
| 244 | − * the PCI bus. Note that there are other caches and buffers on many | |
| 245 | − * busses. In particular driver authors should read up on PCI writes | |
| 246 | − * | |
| 247 | − * It's useful if some control registers are in such an area and | |
| 248 | − * write combining or read caching is not desirable: | |
| 249 | − */ | |
| 250 | −#define ioremap_nocache(offset, size) \ | |
| 251 | − __ioremap_mode((offset), (size), _CACHE_UNCACHED) | |
| 252 | −#define ioremap_uc ioremap_nocache | |
| 230 | +#define ioremap_nocache ioremap | |
| 231 | +#define ioremap_uc ioremap | |
| 253 | 232 | |
| 254 | 233 | /* |
| 255 | 234 | * ioremap_cache - map bus memory into CPU space |