[PATCH RFC v2 05/17] RISC-V: QoS: define CBQRI capacity and bandwidth capabilities

[Reinette Chatre]

Hi Drew,

On 2/14/26 8:25 AM, Drew Fustini wrote:
> On Fri, Feb 13, 2026 at 03:13:42PM -0800, Reinette Chatre wrote:
>> Hi Drew,
> 
> Hi! Thanks for your detailed feedback on this series.
> 
>> On 1/28/26 12:27 PM, Drew Fustini wrote:
>>> Define data structures to store the capacity and bandwidth capabilities
>>> that are discovered for a CBQRI-capable controller.
>>>
>>> Co-developed-by: Adrien Ricciardi <aricciardi at baylibre.com>
>>> Signed-off-by: Adrien Ricciardi <aricciardi at baylibre.com>
>>> Signed-off-by: Drew Fustini <fustini at kernel.org>
>>> ---
>>>  arch/riscv/kernel/qos/internal.h | 128 +++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 128 insertions(+)
>>>
>>> diff --git a/arch/riscv/kernel/qos/internal.h b/arch/riscv/kernel/qos/internal.h
>>> new file mode 100644
>>> index 000000000000..ff2c7eff50be
>>> --- /dev/null
>>> +++ b/arch/riscv/kernel/qos/internal.h
>>> @@ -0,0 +1,128 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +#ifndef _ASM_RISCV_QOS_INTERNAL_H
>>> +#define _ASM_RISCV_QOS_INTERNAL_H
>>> +
>>> +#include <linux/resctrl.h>
>>
>> The include caught my eye but I did not notice any additions in this patch
>> refer to it.
>>
>> Reinette
>>
> 
> I was using this to make resctrl structs available in the code that
> includdes this header:
> 
> arch/riscv/kernel/qos/qos.c
> arch/riscv/kernel/qos/qos_resctrl.c

I see. The changelog made me believe that this patch defines new data structures
used by the patches that follow and the inclusion of resctrl.h created expectation
that some of these new data structures contain resctrl members that I was interested
in seeing used. If keeping this style then a snippet in changelog that explains the
header inclusion/organization would be helpful.
 
> Should I rearrange to include resctrl.h directly where it is needed?
I'll defer to the RISC-V folks since I understand that not all subsystems follow/enforce
rule #1 of Documentation/process/submit-checklist.rst the same (also called "Include
What You Use (IWYU)") quoted for convenience:

	1) If you use a facility then #include the file that defines/declares           
	   that facility.  Don't depend on other header files pulling in ones           
	   that you use.

I have worked with code following different customs and personally I do find code
following IWYU easier to maintain.

Reinette