Messages in this thread | ![/](/images/icornerl.gif) | | From | Stephen Boyd <> | Subject | Re: [PATCH v3 5/7] firmware: coreboot: Remap RAM with memremap() instead of ioremap() | Date | Thu, 09 Aug 2018 15:07:37 -0700 |
| |
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.
| ![\](/images/icornerr.gif) |