On Mon, Jul 27, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: > On Mon, Jul 27, 2015 at 04:31:09PM -0700, Dan Williams wrote: >> On Mon, Jul 27, 2015 at 4:17 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: >> > On Fri, Jul 24, 2015 at 10:38:42PM -0400, Dan Williams wrote: >> >> Existing users of ioremap_cache() are mapping memory that is known in >> >> advance to not have i/o side effects. These users are forced to cast >> >> away the __iomem annotation, or otherwise neglect to fix the sparse >> >> errors thrown when dereferencing pointers to this memory. Provide >> >> memremap() as a non __iomem annotated ioremap_*() in the case when >> >> ioremap is otherwise a pointer to memory. >> > >> > Ok so a special use case. >> > >> >> Outside of ioremap() and >> >> ioremap_nocache(), the expectation is that most calls to >> >> ioremap_<type>() are seeking memory-like semantics (e.g. speculative >> >> reads, and prefetching permitted). These callsites can be moved to >> >> memremap() over time. >> > >> > Such memory-like smantics are not well defined yet and this has caused >> > issues over expectations over a slew of APIs. As you note above >> > your own defined 'semantics' so far for memremap are just that there are >> > no i/o side effects, when the mapped memory is just a pointer to memory, >> > as such I do not think its fair to set the excpectations that we'll >> > switch all other ioremap_*() callers to the same memremap() API. Now, >> > it may be a good idea to use something similar, ie, to pass flags, >> > but setting the expectations outright to move to memremap() without having >> > any agreement having been made over semantics seems uncalled for at this >> > point in time, specially when you are noting that the expectations for >> > both sets of calls are different. >> > >> > So perhaps: >> > >> > " >> > Outside of ioremap() and ioremap_nocache(), all other ioremap_<type>() >> > variant calls are seeking memory-like semantics (e.g. speculative >> > reads, and prefetching permitted) and all calls expecations currently >> > differ depending on architecture. Once and if we get agreement on such >> > semantics we may be able to move such ioremap_*() variant calls to >> > a similar API where the semantics required are clearly spelled out >> > and well defined and passed as arguments. >> >> I still think ioremap_wc(), and now ioremap_uc(), are special and are >> not obvious candidates for conversion to memremap(). > > OK great, then we're in strong agreement, so removing the "Outside of > ioremap() and... over time" might be best then? Otherwise what I posted > seems to reflect the state of affairs better? > Ah yes, I need to clean that up. Thanks! -- 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
