Hi Reinette,

On 12/12/2025 1:22 PM, Reinette Chatre wrote:
> I tried this series against latest upstream kernel and found a conflict with 
> some recent kselftest
> refactoring via commit e6fbd1759c9e ("selftests: complete kselftest include 
> centralization").

Thank you for pointing out this issue.
I will rebase on top of the latest upstream kernel.


> 
> Usually the strategy for resctrl tests is to base them on "next" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git ... 
> but I notice that the
> conflicting change was routed differently and thus difficult to have 
> anticipated.

Thank you for the information.


> 
> Since we are in merge window the maintainer repos are not ready for new 
> features yet.
> Until the repo is ready, could you please base on latest upstream?

No problem. Thank you.
I will rebase on top of the latest upstream kernel, and then send out v4 patch 
series.


> 
> Looking at the series it is not obvious how you want these patches handled 
> though. Patch #3
> is the only one with a "Fixes:" tag (and thus candidate for automatic 
> backport) but it is in
> the middle of the series. It is usually best to have fixes at beginning of 
> series to 
> simplify their handling. Even so, all patches are fixes but only patch #4 has 
> a note

Thank you. I will re-organize the patch series to move patch #3 to the 
beginning of series.


> not to consider for backport. Could you please consider how you want these 
> patches handled,
> communicate that clearly in cover letter, and re-organize the series to have 
> the ones needing
> backport to be at beginning of series?

Thank you for your great suggestions.

I plan to add the maintainer notes in patch #1, patch #2, patch #4 (in original 
patch ordering in v3) and cover letter:

Patch #1 (this patch):
In my opinion, it is an improvement (to these two commits) rather than a real 
fix:
   commit 6220f69e72a5 ("selftests/resctrl: Extend CPU vendor detection")
   commit c603ff5bb830 ("selftests/resctrl: Introduce generalized test 
framework")

What do you think?
If you agree with me, I plan to add a maintainer note that it is not a 
candidate for backport in v4 patch series.

Patch #2:
This patch is not a candidate for backport. I will add a maintainer note in v4 
patch series:
---------------------------
Maintainer note:
Even though this is a fix it is not a candidate for backport since it is
based on another patch series (x86/resctrl: Fix Platform QoS issues for
Hygon) which is in process of being added to resctrl.
---------------------------

Patch #3:
A candidate for backport with "Fixes:" tag. I will move this patch to the 
beginning of series.

Patch #4:
Already has a maintainer note. Keep no change.

Cover letter:
I plan to add a maintainer note outlining how I'd like these patches to be 
handled.


>> -static int detect_vendor(void)
>> +static unsigned int detect_vendor(void)
>>  {
>> -    FILE *inf = fopen("/proc/cpuinfo", "r");
>> -    int vendor_id = 0;
>> +    static bool initialized;
>> +    static unsigned int vendor_id;
>> +    FILE *inf;
> Please maintain the reverse fir ordering.

Thank you. I will fix this issue.


Best regards,
Xiaochen Shen

Reply via email to