BAR 0 is at offset 0x10, and it still contains the value BIOS put there (0xfe010000).
I don't know why Linux couldn't find space for 00:1f.5 BAR 0. Tracing the resource assignment code with 'dyndbg="file drivers/pci/* +p"' and possibly some new trace messages might give a clue.
When Linux fails to assign space, it tries to revert to the BIOS assignment ("BAR 0: trying firmware assignment [mem 0xfe010000-0xfe010fff]"). Apparently we declined to use that BIOS assignment because it "conflicts with Reserved [mem 0xfc800000-0xfe7fffff]". Perhaps Linux should ignore that conflict.
That "Reserved [mem 0xfc800000-0xfe7fffff]" comes from the E820 map, and the Linux handling of that map is somewhat haphazard.
1) Sorry, I don't have a PPA or similar kernel image for you to try.
2) I expected that Windows would move 00:1f.5 BAR 0 to be inside the windows reported by the PCI0 _CRS, but the AIDA64 report shows otherwise:
B00 D1F F05: Intel Ice Point-LP PCH - SPI (Flash) Controller
Offset 000: 86 80 A4 34 06 04 00 00 30 00 80 0C 00 00 00 00
Offset 010: 00 00 01 FE 00 00 00 00 00 00 00 00 00 00 00 00
BAR 0 is at offset 0x10, and it still contains the value BIOS put there (0xfe010000).
I don't know why Linux couldn't find space for 00:1f.5 BAR 0. Tracing the resource assignment code with 'dyndbg="file drivers/pci/* +p"' and possibly some new trace messages might give a clue.
When Linux fails to assign space, it tries to revert to the BIOS assignment ("BAR 0: trying firmware assignment [mem 0xfe010000- 0xfe010fff] "). Apparently we declined to use that BIOS assignment because it "conflicts with Reserved [mem 0xfc800000- 0xfe7fffff] ". Perhaps Linux should ignore that conflict.
That "Reserved [mem 0xfc800000- 0xfe7fffff] " comes from the E820 map, and the Linux handling of that map is somewhat haphazard.