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.
