lkml.org 
[lkml]   [2018]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v3 5/7] firmware: coreboot: Remap RAM with memremap() instead of ioremap()
Date
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.

\
 
 \ /
  Last update: 2018-08-10 00:08    [W:0.059 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site