On Wed, 2015-07-29 at 15:00 -0600, Toshi Kani wrote: > On Wed, 2015-07-29 at 11:33 -0700, Dan Williams wrote: > > On Wed, Jul 29, 2015 at 11:27 AM, Luis R. Rodriguez <mcgrof@xxxxxxxx> > > wrote: > > > On Wed, Jul 29, 2015 at 08:50:04AM +0200, Christoph Hellwig wrote: > > > > On Mon, Jul 27, 2015 at 04:26:03PM -0700, Dan Williams wrote: > > > > > Oh, because all we have at this point is ioremap_cache() which > > > > > silently falls back. It's not until the introduction of > > > > > arch_memremp() where we update the arch code to break that > > > > > behavior. > > > > > > > > Ok, makes sense. Might be worth to document in the changelog. > > > > > > > > > That said, I think it may be beneficial to allow a fallback if > > > > > the > > > > > user cares. So maybe memremap() can call plain ioremap() if > > > > > MEMREMAP_STRICT is not set and none of the other mapping types > > > > > are > > > > > satisfied. > > > > > > > > Is there a real use case for it? Fallback APIs always seem > > > > confusing > > > > and it might make more sense to do this in the caller(s) that > > > > actually > > > > need it. > > > > > > It seems semantics-wise we are trying to separate these two really, > > > so > > > I agree > > > with this. Having a fallback would onloy make things more complicated > > > > > > for any > > > sanitizer / checker / etc, and I don't think the practical gains of > > > having a > > > fallback outweight the gains of having a clear semantic separation on > > > > > > intended > > > memory type and interactions with it. > > > > > > > Yup, consider it dropped. Drivers that want fallback behavior can do > > it explicitly. > > I agree in general. However, for the drivers to be able to fall back > properly, they will need to know the cache type they can fall back with. > ioremap() falls back to the cache type of an existing mapping to avoid > aliasing. Never mind... In this context, we are talking about fallback in case of " API not implemented" on arch. I was talking about fallback in case of aliasing. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
