[PATCH 1/2] arm_mpam: Force __iomem casts

[PATCH 1/2] arm_mpam: Force __iomem casts

[Krzysztof Kozlowski]

Code allocates standard kernel memory to pass to the MPAM, which expects
__iomem.  The code is safe, because __iomem accessors should work fine
on kernel mapped memory, however leads to sparse warnings:

  test_mpam_devices.c:327:42: warning: incorrect type in initializer (different address spaces)
  test_mpam_devices.c:327:42:    expected char [noderef] __iomem *buf
  test_mpam_devices.c:327:42:    got void *
  test_mpam_devices.c:342:24: warning: cast removes address space '__iomem' of expression

Cast the pointer to memory via __force to silence them.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 drivers/resctrl/test_mpam_devices.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/resctrl/test_mpam_devices.c b/drivers/resctrl/test_mpam_devices.c
index 3e8d564a0c64..2de41b47c138 100644
--- a/drivers/resctrl/test_mpam_devices.c
+++ b/drivers/resctrl/test_mpam_devices.c
@@ -324,7 +324,7 @@ static void test_mpam_enable_merge_features(struct kunit *test)
 
 static void test_mpam_reset_msc_bitmap(struct kunit *test)
 {
-	char __iomem *buf = kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
+	char __iomem *buf = (__force char __iomem *)kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
 	struct mpam_msc fake_msc = {};
 	u32 *test_result;
 
@@ -339,7 +339,7 @@ static void test_mpam_reset_msc_bitmap(struct kunit *test)
 	mutex_init(&fake_msc.part_sel_lock);
 	mutex_lock(&fake_msc.part_sel_lock);
 
-	test_result = (u32 *)(buf + MPAMCFG_CPBM);
+	test_result = (__force u32 *)(buf + MPAMCFG_CPBM);
 
 	mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 0);
 	KUNIT_EXPECT_EQ(test, test_result[0], 0);
-- 
2.51.0

[PATCH 2/2] arm64: MAINTAINERS: Include resctrl MPAM driver

[Krzysztof Kozlowski]

No maintainers handling the code (so subsystem maintainers) are shown with
scripts/get_maintainers.pl on MPAM drivers in drivers/resctrl/.  It
seems that there is no dedicated subsystem for resctrl and existing
drivers went through ARM64 port maintainers, so make that explicit to
avoid patches being lost/ignored.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index faa914a5f34d..199058abc152 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3822,6 +3822,8 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
 F:	Documentation/arch/arm64/
 F:	arch/arm64/
+F:	drivers/resctrl/*mpam_*
+F:	include/linux/arm_mpam.h
 F:	drivers/virt/coco/arm-cca-guest/
 F:	drivers/virt/coco/pkvm-guest/
 F:	tools/testing/selftests/arm64/
-- 
2.51.0

Re: [PATCH 2/2] arm64: MAINTAINERS: Include resctrl MPAM driver

[Catalin Marinas]

On Mon, Feb 16, 2026 at 12:02:42PM +0100, Krzysztof Kozlowski wrote:
> No maintainers handling the code (so subsystem maintainers) are shown with
> scripts/get_maintainers.pl on MPAM drivers in drivers/resctrl/.  It
> seems that there is no dedicated subsystem for resctrl and existing
> drivers went through ARM64 port maintainers, so make that explicit to
> avoid patches being lost/ignored.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index faa914a5f34d..199058abc152 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3822,6 +3822,8 @@ S:	Maintained
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>  F:	Documentation/arch/arm64/
>  F:	arch/arm64/
> +F:	drivers/resctrl/*mpam_*
> +F:	include/linux/arm_mpam.h
>  F:	drivers/virt/coco/arm-cca-guest/
>  F:	drivers/virt/coco/pkvm-guest/
>  F:	tools/testing/selftests/arm64/

What's wrong with the current entry?

$ ./scripts/get_maintainer.pl -f drivers/resctrl/mpam_*
James Morse <james.morse@arm.com> (maintainer:MPAM DRIVER)
Ben Horgan <ben.horgan@arm.com> (maintainer:MPAM DRIVER)
Reinette Chatre <reinette.chatre@intel.com> (reviewer:MPAM DRIVER)
Fenghua Yu <fenghuay@nvidia.com> (reviewer:MPAM DRIVER)
linux-kernel@vger.kernel.org (open list)

-- 
Catalin

Re: [PATCH 2/2] arm64: MAINTAINERS: Include resctrl MPAM driver

[Krzysztof Kozlowski]

On 18/02/2026 17:23, Catalin Marinas wrote:
> On Mon, Feb 16, 2026 at 12:02:42PM +0100, Krzysztof Kozlowski wrote:
>> No maintainers handling the code (so subsystem maintainers) are shown with
>> scripts/get_maintainers.pl on MPAM drivers in drivers/resctrl/.  It
>> seems that there is no dedicated subsystem for resctrl and existing
>> drivers went through ARM64 port maintainers, so make that explicit to
>> avoid patches being lost/ignored.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>>  MAINTAINERS | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index faa914a5f34d..199058abc152 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3822,6 +3822,8 @@ S:	Maintained
>>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>>  F:	Documentation/arch/arm64/
>>  F:	arch/arm64/
>> +F:	drivers/resctrl/*mpam_*
>> +F:	include/linux/arm_mpam.h
>>  F:	drivers/virt/coco/arm-cca-guest/
>>  F:	drivers/virt/coco/pkvm-guest/
>>  F:	tools/testing/selftests/arm64/
> 
> What's wrong with the current entry?

I explained in the commit msg:
"No maintainers handling the code (so subsystem maintainers)"

It does not list the maintainers picking up patches, so if you use
standard tools (like b4, patman or scripted get_maintainers), you will
never appear on To/Cc list (relying on git-fallback is wrong).

Of course maybe you will still get the patches with lei/korgalore, so up
to you.


> 
> $ ./scripts/get_maintainer.pl -f drivers/resctrl/mpam_*
> James Morse <james.morse@arm.com> (maintainer:MPAM DRIVER)
> Ben Horgan <ben.horgan@arm.com> (maintainer:MPAM DRIVER)
> Reinette Chatre <reinette.chatre@intel.com> (reviewer:MPAM DRIVER)
> Fenghua Yu <fenghuay@nvidia.com> (reviewer:MPAM DRIVER)
> linux-kernel@vger.kernel.org (open list)
> 


Best regards,
Krzysztof

Re: [PATCH 2/2] arm64: MAINTAINERS: Include resctrl MPAM driver

[Catalin Marinas]

On Wed, Feb 18, 2026 at 05:46:40PM +0100, Krzysztof Kozlowski wrote:
> On 18/02/2026 17:23, Catalin Marinas wrote:
> > On Mon, Feb 16, 2026 at 12:02:42PM +0100, Krzysztof Kozlowski wrote:
> >> No maintainers handling the code (so subsystem maintainers) are shown with
> >> scripts/get_maintainers.pl on MPAM drivers in drivers/resctrl/.  It
> >> seems that there is no dedicated subsystem for resctrl and existing
> >> drivers went through ARM64 port maintainers, so make that explicit to
> >> avoid patches being lost/ignored.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >> ---
> >>  MAINTAINERS | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index faa914a5f34d..199058abc152 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -3822,6 +3822,8 @@ S:	Maintained
> >>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> >>  F:	Documentation/arch/arm64/
> >>  F:	arch/arm64/
> >> +F:	drivers/resctrl/*mpam_*
> >> +F:	include/linux/arm_mpam.h
> >>  F:	drivers/virt/coco/arm-cca-guest/
> >>  F:	drivers/virt/coco/pkvm-guest/
> >>  F:	tools/testing/selftests/arm64/
> > 
> > What's wrong with the current entry?
> 
> I explained in the commit msg:
> "No maintainers handling the code (so subsystem maintainers)"

Yeah, I realised what you meant after sending my reply ;).

> It does not list the maintainers picking up patches, so if you use
> standard tools (like b4, patman or scripted get_maintainers), you will
> never appear on To/Cc list (relying on git-fallback is wrong).

The arm64 maintainers won't proactively pick these patches up unless we
are asked by the MPAM maintainers. I don't mind whether the patches go
in via the arm64 or Greg's drivers tree. We just queued the first drop
as it touched arm64.

Let's see how it goes but I know little about MPAM, so just being on cc
won't make much difference. I rely on the current MPAM maintainers to
tell me what to merge.

Thanks.

-- 
Catalin

Re: [PATCH 2/2] arm64: MAINTAINERS: Include resctrl MPAM driver

[Krzysztof Kozlowski]

On 18/02/2026 18:13, Catalin Marinas wrote:
> On Wed, Feb 18, 2026 at 05:46:40PM +0100, Krzysztof Kozlowski wrote:
>>>
>>> What's wrong with the current entry?
>>
>> I explained in the commit msg:
>> "No maintainers handling the code (so subsystem maintainers)"
> 
> Yeah, I realised what you meant after sending my reply ;).
> 
>> It does not list the maintainers picking up patches, so if you use
>> standard tools (like b4, patman or scripted get_maintainers), you will
>> never appear on To/Cc list (relying on git-fallback is wrong).
> 
> The arm64 maintainers won't proactively pick these patches up unless we
> are asked by the MPAM maintainers. I don't mind whether the patches go
> in via the arm64 or Greg's drivers tree. We just queued the first drop
> as it touched arm64.
> 
> Let's see how it goes but I know little about MPAM, so just being on cc
> won't make much difference. I rely on the current MPAM maintainers to
> tell me what to merge.


OK, there are few subsystems (e.g. cdx) doing something similar -
listing only reviewing maintainer, which later has to poke the actual
maintainer picking up patches. I find it confusing practice and might
lead to patches being lost on the mailing list (happened for example
with cdx...), which is very poor contributor experience, but I
understand you might not want to maintain them (same happened for cdx...).

In that case MPAM folks, please kindly review and pick up only the first
patch. Or tell me what should be done...

Best regards,
Krzysztof

Re: [PATCH 1/2] arm_mpam: Force __iomem casts

[Ben Horgan]

Hi Krzysztof,

On 2/16/26 11:02, Krzysztof Kozlowski wrote:
> Code allocates standard kernel memory to pass to the MPAM, which expects
> __iomem.  The code is safe, because __iomem accessors should work fine
> on kernel mapped memory, however leads to sparse warnings:
> 
>   test_mpam_devices.c:327:42: warning: incorrect type in initializer (different address spaces)
>   test_mpam_devices.c:327:42:    expected char [noderef] __iomem *buf
>   test_mpam_devices.c:327:42:    got void *
>   test_mpam_devices.c:342:24: warning: cast removes address space '__iomem' of expression
> 
> Cast the pointer to memory via __force to silence them.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  drivers/resctrl/test_mpam_devices.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/resctrl/test_mpam_devices.c b/drivers/resctrl/test_mpam_devices.c
> index 3e8d564a0c64..2de41b47c138 100644
> --- a/drivers/resctrl/test_mpam_devices.c
> +++ b/drivers/resctrl/test_mpam_devices.c
> @@ -324,7 +324,7 @@ static void test_mpam_enable_merge_features(struct kunit *test)
>  
>  static void test_mpam_reset_msc_bitmap(struct kunit *test)
>  {
> -	char __iomem *buf = kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
> +	char __iomem *buf = (__force char __iomem *)kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
>  	struct mpam_msc fake_msc = {};
>  	u32 *test_result;
>  
> @@ -339,7 +339,7 @@ static void test_mpam_reset_msc_bitmap(struct kunit *test)
>  	mutex_init(&fake_msc.part_sel_lock);
>  	mutex_lock(&fake_msc.part_sel_lock);
>  
> -	test_result = (u32 *)(buf + MPAMCFG_CPBM);
> +	test_result = (__force u32 *)(buf + MPAMCFG_CPBM);
>  
>  	mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 0);
>  	KUNIT_EXPECT_EQ(test, test_result[0], 0);


This change looks good to me. As sparse is more broken I needed to use
the patch from [1] to reproduce this. Copied here for convenience.

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 2b30a0529d48..90536b2bc42e 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -14,8 +14,8 @@ struct vm_area_struct;
 struct mempolicy;

 /* Helper macro to avoid gfp flags if they are the default one */
-#define __default_gfp(a,...) a
-#define default_gfp(...) __default_gfp(__VA_ARGS__ __VA_OPT__(,)
GFP_KERNEL)
+#define __default_gfp(a,b,...) b
+#define default_gfp(...) __default_gfp(,##__VA_ARGS__,GFP_KERNEL)

 /* Convert GFP flags to their corresponding migrate type */
 #define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)

There is a kernel test robot report [2] and that asks for these tags:

Reported-by: kernel test robot <lkp@intel.com>
Closes:
https://lore.kernel.org/oe-kbuild-all/202512160133.eAzPdJv2-lkp@intel.com/

Acked-by: Ben Horgan <ben.horgan@arm.com>

[1]
https://lore.kernel.org/all/CAHk-=wijD-giccF6sJ+BdJpGDX9kPEUT6kryaQG0GRyJ3QQwng@mail.gmail.com/
[2] https://lore.kernel.org/all/202512160133.eAzPdJv2-lkp@intel.com/

Thanks,

Ben

Re: [PATCH 1/2] arm_mpam: Force __iomem casts

[Krzysztof Kozlowski]

On 27/02/2026 15:06, Ben Horgan wrote:
> Hi Krzysztof,
> 
> On 2/16/26 11:02, Krzysztof Kozlowski wrote:
>> Code allocates standard kernel memory to pass to the MPAM, which expects
>> __iomem.  The code is safe, because __iomem accessors should work fine
>> on kernel mapped memory, however leads to sparse warnings:
>>
>>   test_mpam_devices.c:327:42: warning: incorrect type in initializer (different address spaces)
>>   test_mpam_devices.c:327:42:    expected char [noderef] __iomem *buf
>>   test_mpam_devices.c:327:42:    got void *
>>   test_mpam_devices.c:342:24: warning: cast removes address space '__iomem' of expression
>>
>> Cast the pointer to memory via __force to silence them.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>>  drivers/resctrl/test_mpam_devices.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/resctrl/test_mpam_devices.c b/drivers/resctrl/test_mpam_devices.c
>> index 3e8d564a0c64..2de41b47c138 100644
>> --- a/drivers/resctrl/test_mpam_devices.c
>> +++ b/drivers/resctrl/test_mpam_devices.c
>> @@ -324,7 +324,7 @@ static void test_mpam_enable_merge_features(struct kunit *test)
>>  
>>  static void test_mpam_reset_msc_bitmap(struct kunit *test)
>>  {
>> -	char __iomem *buf = kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
>> +	char __iomem *buf = (__force char __iomem *)kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
>>  	struct mpam_msc fake_msc = {};
>>  	u32 *test_result;
>>  
>> @@ -339,7 +339,7 @@ static void test_mpam_reset_msc_bitmap(struct kunit *test)
>>  	mutex_init(&fake_msc.part_sel_lock);
>>  	mutex_lock(&fake_msc.part_sel_lock);
>>  
>> -	test_result = (u32 *)(buf + MPAMCFG_CPBM);
>> +	test_result = (__force u32 *)(buf + MPAMCFG_CPBM);
>>  
>>  	mpam_reset_msc_bitmap(&fake_msc, MPAMCFG_CPBM, 0);
>>  	KUNIT_EXPECT_EQ(test, test_result[0], 0);
> 
> 
> This change looks good to me. As sparse is more broken I needed to use
> the patch from [1] to reproduce this. Copied here for convenience.

The branch from Al Viro was working fine at that time, now merged to master.

> 
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 2b30a0529d48..90536b2bc42e 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -14,8 +14,8 @@ struct vm_area_struct;
>  struct mempolicy;
> 
>  /* Helper macro to avoid gfp flags if they are the default one */
> -#define __default_gfp(a,...) a
> -#define default_gfp(...) __default_gfp(__VA_ARGS__ __VA_OPT__(,)
> GFP_KERNEL)
> +#define __default_gfp(a,b,...) b
> +#define default_gfp(...) __default_gfp(,##__VA_ARGS__,GFP_KERNEL)
> 
>  /* Convert GFP flags to their corresponding migrate type */
>  #define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
> 
> There is a kernel test robot report [2] and that asks for these tags:

That I did not know. Anyone can run sparse, as I am doing every now and
then, and find issues.

> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202512160133.eAzPdJv2-lkp@intel.com/
> 
> Acked-by: Ben Horgan <ben.horgan@arm.com>

Best regards,
Krzysztof

Re: [PATCH 1/2] arm_mpam: Force __iomem casts

[James Morse]

Hi Krzysztof, Ben,

On 27/02/2026 14:51, Krzysztof Kozlowski wrote:
> On 27/02/2026 15:06, Ben Horgan wrote:
>> On 2/16/26 11:02, Krzysztof Kozlowski wrote:
>>> Code allocates standard kernel memory to pass to the MPAM, which expects
>>> __iomem.  The code is safe, because __iomem accessors should work fine
>>> on kernel mapped memory, however leads to sparse warnings:
>>>
>>>   test_mpam_devices.c:327:42: warning: incorrect type in initializer (different address spaces)
>>>   test_mpam_devices.c:327:42:    expected char [noderef] __iomem *buf
>>>   test_mpam_devices.c:327:42:    got void *
>>>   test_mpam_devices.c:342:24: warning: cast removes address space '__iomem' of expression
>>>
>>> Cast the pointer to memory via __force to silence them.

>>> diff --git a/drivers/resctrl/test_mpam_devices.c b/drivers/resctrl/test_mpam_devices.c
>>> index 3e8d564a0c64..2de41b47c138 100644
>>> --- a/drivers/resctrl/test_mpam_devices.c
>>> +++ b/drivers/resctrl/test_mpam_devices.c
>>> @@ -324,7 +324,7 @@ static void test_mpam_enable_merge_features(struct kunit *test)
>>>  
>>>  static void test_mpam_reset_msc_bitmap(struct kunit *test)
>>>  {
>>> -	char __iomem *buf = kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
>>> +	char __iomem *buf = (__force char __iomem *)kunit_kzalloc(test, SZ_16K, GFP_KERNEL);
>>>  	struct mpam_msc fake_msc = {};
>>>  	u32 *test_result;
>>>  

>> This change looks good to me.

[...]

>> Acked-by: Ben Horgan <ben.horgan@arm.com>


Thanks! I've picked this for a fixes branch. I'm not sure what Will or Catalin will think
this needs fixing during the release as the driver is behind CONFIG_EXPERT. I'll ask...


Thanks,

James