(And, unless you're in a case where the fix is not simple or you fear about possible complications, no need to upload a review for this, just commit the fix.)

Haven't tried to build it myself, but if that fixes the build, just go ahead. As a side note, I'll post a review removing this code relatively soon.

Two more things to consider. First, you finally reduce items expected to be read-only to an integer (field value in struct acpi_cppc_rdonly_item), but some of these are dynamic and may change during runtime, in which case we have to keep the full register specification. Second, in the _CPC example I sent you offline for an AMD machine where processors do not report the CPPC extended feature flag, most present items have the PCC access method, so won't be covered by the code here. In the same example, there are only two FFH, for the ReferencePerformanceCounterRegister and DeliveredPerformanceCounterRegister, and the addresses seem to correspond to the MPERF and APERF MSR numbers respectively.

So, as I feared, the CPC parsing library needs significant work.

Disappearance of SYS_RES_FFH (see other revisions in the stack) makes this obsolete.

As noted on previous revisions, SYS_RES_FFH should not exist, nor should acpi_ffh_write() and acpi_ffh_read(). So, basically, this needs a full rework.

acpi_get_rman() should always return NULL on FFH, and it's absolutely inconceivable to match devices on FFH values.

I do not think that this change makes sense, and probably would just drop it.

Looks good. One suggestion in an inline comment. Only thing now is the dependency on the CPPC lib, I'll review the other revisions and come back to here.

In D58086#1332799, @kib wrote:

the second is out of line of existing code.

Be consistent and declare all small helpers as inline.

In D57658#1332524, @kib wrote:

Peter finished testing the patch. Do anybody have more comments about it? I intend to commit it shortly.

More compact tests on the max LVT slot, based on D58110.

In D58086#1332368, @kib wrote:

I thought that the intent was that the thermal handler is installed only when the CPU supports the interrupt.

In D58000#1332042, @minsoochoo0122_proton.me wrote:

Fit comment in one line (99 columns)

In D58065#1332040, @minsoochoo0122_proton.me wrote:

Since I don't have commit bit yet, could you push it for me? Thanks:)

Edits from gperciva@

New D58086 for you to check.

Going to commit this. Will apply a few additional minor style (mostly, names, and a declaration moved to the corresponding block) changes in a separate commit.

Looks good (see also inline comment). Could you update the Phab revision's description with the new commit message?

Looks much better like that. :-) "Suggested by: olce" appreciated.

Cater to gpercival's comments

However, if you feel that the renaming is necessary and local variables should be named runq, I'm learning towards runq_global over global_runq since it has similar naming to runq_pcpu although the name is not grammatically correct.

• Add mention to D58000's work

• 4BSD: Switch from MAXCPU fixed-length array to DPCPU for runq_pcpu (D58000 please review)

The commit message is not completely clear on first read, in particular with respect to why the change here saves memory. Also, there are typos. Suggestions:

Fix typo (missing space).

Fix item lists.

Removing the hyphen in the first line is fine, but then that should be mentioned in the commit message. I can add a sentence to that effect myself. Which mail do you want to use? The one that can be inferred from your Phabricator login? I also see a mail at "zohomail" in the tree that could match. If you have to disclose the full name and don't want to do that here, then please mail it to me (olce@).

Thanks, will do some followup next week.

Simplify.

Looks good modulo some minor style (in a broad sense) improvements. To ease things, I could apply these changes myself on commit. Please tell me if you object to that.

In D44454#1327923, @kib wrote:

Ed, feel free to merge this review.