de67080fbe
The NUM_APID value was derived from kernel device tree sources, but I made a conversion mistake: the amount of bytes in the APID map is the total size of the "core" register range (0x1100) minus the offset of the APID map in that range (0x900). This is of course 0x1100 - 0x900 = 0x800 and not 0x200, so the amount of 4-byte integers it can fit is not 0x80 but 0x200. Fix this and make the math more explicit so it can be more easily factored out and adjusted if that becomes necessary for a future SoC. Also fix a dangerous typo in REG_APID_MAP() where the macro would reference a random variable `i` rather than its argument (`apid`), and we just got lucky that the only caller in the current code happened to pass in a variable called `i` as that argument. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I049dd044fa5aeb65be0e7b12150afd6eb4bac0fa |
||
|---|---|---|
| .. | ||
| common | ||
| qtiseclib | ||
| sc7180 | ||