It seems that access to MMIO registers is wrong here, in a similar way as for the proposed Intel PMC driver (D54881). Offsets RAPL_PKG_POWER_* are applied to BAR(0), whereas they should be applied to MCHBAR in the host bridge's PCI config space. See also inline comments for some nits.

I have a bit alarming concerns about how this (and D54881) have been coded, on which information they are based exactly, how they have been tested and where all this is heading.

The supposed device ID according to the Intel Gen10 doc is 0x3Exx (should be at PCI 0:0:0), and actually refers to the host bridge, whereas here 0x1903 is used. I can see a mention of 0x1900 in some Gen6 doc. Concern here is, IIUC, you are basically claiming the host bridge device just for its "thermal" part. If no other driver claims it at the moment, that's fine (a very quick search did not return candidates), but further dev may need to refactor this into a kind of sub-driver. At the very least, this needs to be documented.

In the Intel documents I have read (which include "Intel 10th Gen Core Processor Datasheet Vol 2" that you're quoting explicitly), I see no mention at all of any B0D4 thermal device. And there's actually no use of this ID anywhere in this driver, it's just mentioned in the main source herald comment and the manual page. Where does this ID come from? What does it mean? If it has no bearing on what is done here, it should be removed, else its meaning/purpose should be made explicit. After some research, let me guess: I suspect this ID comes from Linux's processor_thermal_device_pci_legacy.c, where it appears in a comment, unexplained, and is not used anywhere in that driver either. And, thus, I suspect some the aspects of this driver have been inspired by some Linux code, which would not be wrong but should be acknowledged.

The offsets used look problematic. RAPL_PKG_POWER_INFO is 0x5994, which according to Intel's doc is RP_STATE_LIMITS, whose description is: "This register allows SW to limit the maximum base frequency for the Integrated GFX Engine (GT) allowed during run-time.", which just doesn't seem to be the information you are after. RAPL_PKG_POWER_INFO is 0x59A0, an offset that does not appear at all in the same Intel doc. No more luck in the datasheet for Intel Gen6 (Skylake) processors. Where do these offset come from? Typically, I see a different offset in Linux that should be used for RAPL_PKG_POWER_INFO.

I suspect you have been "vibe coding". A mention that it's the case and which IA was used would be appropriate. And let me add that, while getting some help from AI is OK, it does not exempt you (and reviewers) from doing the work of checking what the produced code actually does and if it matches existing docs and possibly other code, and documenting thoroughly your research and findings. The work you're not doing yourself is on the reviewers, which does not scale and, to be frank, can be annoying. How was this code tested? Given the problem reported at start, I don't see how you can get any values that make sense as power values.

In Linux, the RAPL driver apparently has 3 ways of accessing registers, among which there is access through the PCH (as you're trying to do here), non-architectural MSRs and TPMI, which I didn't know about but quickly explored (see, e.g. https://github.com/intel/tpmi_power_management). I'm wondering if creating a PCH driver, where each specific model must be added, is really worth it (but if you have changes for other models cooking). Personally, I'm interested in having power statistics for recent generation of Intel platforms (>= Gen 10, and in particular Core Ultra Series 1), and generally think we should target modern hardware as much as possible. Do you have any idea about what differences there are in terms of hardware support and "end-user" functionality between the 3 access methods I have just mentioned?