From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Date: Thu, 30 Nov 2017 17:37:27 +0000 > Well, the whole point of using memremap() instead of ioremap() is that > the region has memory semantics, i.e., we read the MAC address and the > DMA engine microcode from it. If memremap() itself is flawed in this > regard, I agree we should fix it. But as I understand it, this is > really an implementation problem in memremap() [the fact that it falls > back to ioremap()] and not a problem in this driver. > > So what alternative would you propose in this case? > > BTW, this should be IOREMAP_WC not IOREMAP_WT, because the EEPROM on > the platform in question does not tolerate cached mappings (or rather, > shareable mappings). ioremap_wt() happens to result in device mappings > rather than writethrough cacheable mappings, but this is another > problem in itself. Once arm64 fixes ioremap_wt(), this code will no > longer work on the SynQuacer SoC. It doesn't "fall back", it directly uses ioremap_wt() for non-RAM mappings. It you look, most architectures do a "#define iomrep_wt ioremap" -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
