[M] Change in coreboot[master]: soc/amd/spi: Mmap 32M/64M flash

[Julius Werner (Code Review)]

Attention is currently required from: Bao Zheng, Jason Glenesk, Raul Rangel, Marshall Dawson, Matt DeVillier, Zheng Bao, Martin Roth, Fred Reitberger, Felix Held.

Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74260 )

Change subject: soc/amd/spi: Mmap 32M/64M flash
......................................................................

Patch Set 7:

(1 comment)

File src/soc/amd/common/block/lpc/spi_map_big.c:

https://review.coreboot.org/c/coreboot/+/74260/comment/111d9845_69fcdbba 
PS7, Line 30: 	spi_write32(SPI_ROM_PAGE, offset / ROM_MAP_SIZE);
I may misunderstand what this does, but I don't think this is safe. It looks like you have a single SPI_ROM_PAGE register that determines what part of the SPI flash is currently mapped in mdev->base?

If so, you can't do this. rdev mappings are allowed to be valid concurrently, i.e. it's legal for someone to do
```
uint32_t *a = rdev_mmap(your_rdev, 0, 0x1000);
uint32_t *b = rdev_mmap(your_rdev, 0x100000, 0x1000);
uint32_t sum = *a + *b;
rdev_munmap(a);
rdev_munmap(b);
```
I think with your implementation here that would explode? You can't have every mmap() call invalidate the pointer returned by the previous one. If your hardware doesn't support keeping different mappings alive concurrently, you'll have to fall back to memory-backed mappings via mmap_helper like drivers/spi/cbfs_spi.c does.