summaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorAaron Durbin <adurbin@chromium.org>2020-07-01 00:01:33 -0600
committerAaron Durbin <adurbin@chromium.org>2020-07-02 15:55:46 +0000
commitc5bb02f2ecb96a2a4cabba139c8ca1e15af2621a (patch)
tree1a8daa96a532f24626db1a9b02692fb4696adc77 /MAINTAINERS
parent57285820a3a31dfd8cd80861e0f772a74d98c9ec (diff)
downloadcoreboot-c5bb02f2ecb96a2a4cabba139c8ca1e15af2621a.tar.xz
soc/amd/common: fix SPI bar resource usage
The ACPI code was not masking off the correct bits for publishing the SPI bar to the OS. It resulted in a dmesg messagelike: system 00:00: [mem 0xfec10002-0xfec11001] has been reserved And /proc/iomem entry fec10002-fec11001 : pnp 00:00 These addresses are wrong because they are including bits of a register that are not a part of the address. Moreover, the code does not publish the eSPI register area either. The eSPI registers live at 0x10000 added to the SPI bar. Lastly, both regions are less than a page so only report a page of usage for each. Stoney Ridge's SPI bar register defines the address as 31:6 while Picasso's SPI bar register defines the address as 31:8. Use Picasso's valid mask for both cases because no one is assigning addresses that are aligned to less than 256 bytes. With the fixes, dmesg reports: system 00:00: [mem 0xfec10000-0xfec10fff] has been reserved system 00:00: [mem 0xfec20000-0xfec20fff] has been reserved And /proc/iomem indicates: fec10000-fec10fff : pnp 00:00 fec20000-fec20fff : pnp 00:00 BUG=b:160290629 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I130b5ad26d9e13b44c25fbb35a05389f9e8841ab Reviewed-on: https://review.coreboot.org/c/coreboot/+/42959 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions