Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754903AbbG1Ac6 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 27 Jul 2015 20:32:58 -0400
Received: from mail-wi0-f174.google.com ([209.85.212.174]:37390 "EHLO
	mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754873AbbG1Acz (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 27 Jul 2015 20:32:55 -0400
MIME-Version: 1.0
In-Reply-To: <20150727234351.GW30479@wotan.suse.de>
References: <20150725023649.8664.59145.stgit@dwillia2-desk3.amr.corp.intel.com>
	<20150725023842.8664.97620.stgit@dwillia2-desk3.amr.corp.intel.com>
	<20150727231755.GV30479@wotan.suse.de>
	<CAPcyv4i07wV1Mf1XCs-U98w979enk9PYKquh7CSMcJv0T1kH1Q@mail.gmail.com>
	<20150727234351.GW30479@wotan.suse.de>
Date: Mon, 27 Jul 2015 17:32:54 -0700
Message-ID: <CAPcyv4i=QPHxHp-VZ63tKbVyBW66BgGXBq0Z3K8gnZMVd=1r6A@mail.gmail.com>
Subject: Re: [PATCH v2 08/25] arch: introduce memremap()
From: Dan Williams <dan.j.williams@intel.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, linux-arch@vger.kernel.org,
        Arnd Bergmann <arnd@arndb.de>,
        "linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Russell King <rmk+kernel@arm.linux.org.uk>,
        Christoph Hellwig <hch@lst.de>,
        "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2960
Lines: 56

On Mon, Jul 27, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@suse.com> 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@suse.com> 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/