Hi Ben, On 28/08/2025 11:11, Ben Horgan wrote: > On 8/22/25 16:30, James Morse wrote: >> MPAM supports more features than are going to be exposed to resctrl. >> For partid other than 0, the reset values of these controls isn't >> known. >> >> Discover the rest of the features so they can be reset to avoid any >> side effects when resctrl is in use. >> >> PARTID narrowing allows MSC/RIS to support less configuration space than >> is usable. If this feature is found on a class of device we are likely >> to use, then reduce the partid_max to make it usable. This allows us >> to map a PARTID to itself. >> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c >> index 8f6df2406c22..aedd743d6827 100644 >> --- a/drivers/resctrl/mpam_devices.c >> +++ b/drivers/resctrl/mpam_devices.c >> @@ -964,6 +1054,29 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid, >> >> if (mpam_has_feature(mpam_feat_mbw_prop, rprops)) >> mpam_write_partsel_reg(msc, MBW_PROP, bwa_fract); >> + >> + if (mpam_has_feature(mpam_feat_cmax_cmax, rprops)) >> + mpam_write_partsel_reg(msc, CMAX, cmax); >> + >> + if (mpam_has_feature(mpam_feat_cmax_cmin, rprops)) >> + mpam_write_partsel_reg(msc, CMIN, 0); > Missing reset for cmax_cassoc. I wonder if it makes sense to have > separate enums for partitioning features, which require reset, and the rest. Fixed. They all need resetting because the architecture doesn't guarantee the state of controls out of reset for PARTID other than zero. (or - when the MSC are reset). I think those two lists would just be those that are reset to zero, as opposed to some other value. Given the register names have to be listed here, I don't think its any worse to have the hand-picked reset value. Thanks, James
