Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
To:     Aaron Durbin <adurbin@chromium.org>,
        Julius Werner <jwerner@chromium.org>
From:   Stephen Boyd <swboyd@chromium.org>
In-Reply-To: <CAODwPW8x=ghbVpo4q48jh-xGScP+2O_Vt7LTtSqhLvAAnCVXuA@mail.gmail.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Wei-Ning Huang <wnhuang@chromium.org>,
        Julius Werner <jwerner@chromium.org>,
        Brian Norris <briannorris@chromium.org>, samuel@sholland.org
References: <20180809171722.144325-1-swboyd@chromium.org>
 <20180809171722.144325-6-swboyd@chromium.org>
 <CAODwPW8x=ghbVpo4q48jh-xGScP+2O_Vt7LTtSqhLvAAnCVXuA@mail.gmail.com>
Message-ID: <153385245791.220756.10097093170204882190@swboyd.mtv.corp.google.com>
User-Agent: alot/0.7
Subject: Re: [PATCH v3 5/7] firmware: coreboot: Remap RAM with memremap() instead of
 ioremap()
Date:   Thu, 09 Aug 2018 15:07:37 -0700
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Quoting Julius Werner (2018-08-09 11:24:29)
> One thing to note is that we still want this space to be mappable by
> userspace applications via /dev/mem, so we need to make sure that
> there's no weird memory type mismatch that causes problems with that.
> Adding Aaron to see if he has any concerns here, since I think he's
> seen something like that in the past (not sure if it was related to
> what this kernel driver does).
> =

> Can you please test this on an x86 Chromebook and run the 'cbmem'
> userspace utility, make sure it doesn't fail after this?

Sure!

> =

> Also, stupid question after taking a step back and looking at this
> again: why do we keep a mapping alive for the lifetime of the driver
> at all? It used to be necessary when this driver was
> find-entry-on-demand, but nowadays it just goes through all entries
> once at probe time and immediately memcpy_fromio()s out all the
> relevant information into (struct coreboot_device)s. After that we're
> done accessing the "real" coreboot table, forever. Why not just unmap
> it again at the end of coreboot_table_init()?

Yes, we just copy everything over so it makes it simpler to just unmap
at the end of coreboot_table_init(). Then userspace is free to make a
questionable mapping into system RAM to find the table itself.

I'll make this change.