The sysctl_handle_int() call doesn't need to be inside the sched_bind() section, it should be moved earlier.

There should be an extra newline after local variable declarations.

The AND is redundant. Is there a typo here?

Could you rename the AMD_CPPC_ prefix to AMD_CPPC_CAPS_1_, just to make it apparent that these are applicable (only) to the CAPS 1 MSR?

Same here please, AMD_CPPC_ => AMD_CPPC_REQUEST_.

You're basically open-coding some AMD_CPPC_ macros (those to prefix with AMD_CPPC_CAPS_1_) here. Please use the macros instead.

That second read actually reads the same MSR. I think you should completely remove data2 and use data instead. This distinction made sense in the Intel case as there is a specific MSR targeted at the package (MSR_IA32_HWP_REQUEST_PKG) but there's no such thing in AMD processors.

Even if there is no specific hardware support for package control on AMD processors, I think that providing this functionality to users is beneficial, in that it simplifies a lot the configuration of the "baseline" case where all cores are set to the same value.

You probably meant PSTATE_CPPC here, as bailing out in the case of PSTATE_CPPC_PKG_CTRL does not seem to make sense.

This is in the wrong place. It must be moved between the lines val = ((r >> 24) & 0xFFULL) * 100 / 0xff; and if (val > 100) {.

It would be better to use AMD_CPPC_REQUEST_ENERGY_PERF_BITS here, even if that's more verbose. With it, we immediately know that the code is correct without having to check if the shift and mask are correct.

If you find that too verbose, factor out the formula into a macro.

Missing input/output at this point (see previous comment).

Generally, support for PSTATE_CPPC_PKG_CTRL is missing (as said above, I think this functionality is

We may want to mimick what happens in the Intel counterpart, which means that setting the knob for one core should affect all the other cores. If so, basically, when PSTATE_CPPC_PKG_CTRL is set, we have to loop over all CPUs for the setting part.

Same as above, it would be preferable to use a macro based only on AMD_CPPC_REQUEST_ENERGY_PERF_BITS and avoid the hardcoded 24.

Aren't we supposed to use MSR C001_0280 ("Performance Time Stamp Counter (CU_PTSC)") here? Or are we sure the regular TSC is just invariant if PSTATE_CPPC_PWR_CALC is set?

But maybe that's not worth bothering, as it appears most AMD processors do not support PSTATE_CPPC_PWR_CALC (i.e., only some of family 16h do, skimming various PPR manuals).

Similarly as above, I'd prefer macros here on the right-hand side of |=, and no hardcoded shifts (and proper mask applied to the new value, just in case, even though you aptly chose uint8_t as the type for the cppc_settings fields).

Since you (rightly) added an occurrence of a call to device_set_desc() earlier, you can remove this one (redundant).