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:     Julius Werner <jwerner@chromium.org>
From:   Stephen Boyd <swboyd@chromium.org>
In-Reply-To: <153386966793.37448.12640092735399834661@swboyd.mtv.corp.google.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Wei-Ning Huang <wnhuang@chromium.org>,
        Brian Norris <briannorris@chromium.org>, samuel@sholland.org
References: <20180809171722.144325-1-swboyd@chromium.org>
 <20180809171722.144325-8-swboyd@chromium.org>
 <CAODwPW8eg2WOh9-Raeb8Q65E-5D7RDheDU8e+H68FHGa0MS37A@mail.gmail.com>
 <153385579866.220756.16086660810932774163@swboyd.mtv.corp.google.com>
 <CAODwPW84FYK3k5=n4gQ4EPJExhQ59LCEi31ZYi2Bq2y9FH_E_A@mail.gmail.com>
 <CAODwPW8+QSittJdNLWpWKU=JNJa5bssMHQ4ER4CfnUAWaL1JGA@mail.gmail.com>
 <153386966793.37448.12640092735399834661@swboyd.mtv.corp.google.com>
Message-ID: <153394348544.37448.7231279350981818561@swboyd.mtv.corp.google.com>
User-Agent: alot/0.7
Subject: Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive
 access
Date:   Fri, 10 Aug 2018 16:24:45 -0700
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Quoting Stephen Boyd (2018-08-09 19:54:27)
> What's with the top posting? ;-)
> =

> Quoting Julius Werner (2018-08-09 16:44:43)
> > Actually, looking at what IO_STRICT_DEVMEM really does, would it
> > really prevent userspace accesses to these areas? Because it seems
> > that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
> > while I can't fully follow how the kernel assigns that, comments
> > suggest that this is only set when "Driver has marked this resource
> > busy".
> =

> Requesting the memory region as is done in this patch marks it as busy.
> =

> > =

> > So after you make the change to the other patch where we immediately
> > unmap the coreboot table again at the end of the probe() function,
> > shouldn't it become available to userspace again even with
> > IO_STRICT_DEVMEM set?
> =

> Yes, if we unmap the region immediately after devices are populated then
> this whole point is moot with the assumption that this code isn't
> running at the same time as the cbmem utility. I've done this already
> and it is working on arm. I still need to build/boot/test on an x86
> platform which I should be able to do tomorrow.
> =


I tried my latest version of the patches (unplubished so far) and those
work on x86 with cbmem. So things look good and we don't need to keep
the mapping around.