Re: [PATCH v3 01/16] arm_mpam: let low level MSC read accessors return an error

[Andre Przywara <andre.przywara@arm.com>]

Hi Jonathan,

many thanks for the time you spent on this - though it wasn't 
particularly pretty, I guess.

This is just a quick reply, unfortunately (well...) I will be on 
holidays next week, so cannot reply in detail now.

On 7/10/26 20:11, Jonathan Cameron wrote:
> On Fri, 10 Jul 2026 16:45:05 +0200
> Andre Przywara <andre.przywara@arm.com> wrote:
> 
>> The upcoming MPAM-Fb support does not use MMIO primitives to access an
>> MSC, but employs a shared-memory/doorbell based firmware protocol.
>> Its complexity means that is must be able to handle errors, whereas we
>> always assume an MSC access succeeds today.
>>
>> Change the __mpam_read_reg() low level accessor function to return the
>> requested data through a pointer, and return an error code instead.
>> At the moment this is always 0, but this will change with alternative
>> MSC access methods.
>> Change all users of those MSC read wrappers to comply with the new
>> prototype, though at the moment without propagating any errors.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> Why do it in this order? It seems like it is a path for some code churn
> from patch to path.

Well, this is pain however you do this - as you figured. And I knew this 
before, that's why I avoided this in v1, but then found we have to bite 
the bullet at some point anyway, so we could as well just do it now.

So I did the change in one go, and the diff was completely unreadable 
and even more so unreviewable. Then I figured to start with the actual 
root cause: the low level accessors, to show the motivation, then split 
the rest up in reasonably small chunks. And with the unavoidable 
dependencies, this led to the structure you see, with the added churn of 
requested changes and refactors between v2 and v3.

> If you started at the outermost calls and
> worked in adding error handling at each layer, you wouldn't end up with
> the change here to add the parameter, then the same lines changed again
> to stash the new return value. Those lines would change just once.
> Maybe I'm wrong though and it ends up even messier.

Well, I guess there are a few ways to do this, but I doubt there is a 
really great one. And as you can imagine, there is little fun in trying 
a number of them, then comparing them. Doing this the first time was 
already painful. So I thought to just pick one approach and see what 
people say - I guess this was the wrong approach then :-(

> Or as you suggest, maybe just squash the patches, which will also
> remove the churn.
> 
> Jonathan
> 
>> @@ -226,10 +230,11 @@ static inline void _mpam_write_monsel_reg(struct mpam_msc *msc, u16 reg, u32 val
>>   
>>   static bool mpam_msc_check_aidr(struct mpam_msc *msc)
>>   {
>> -	u32 aidr = __mpam_read_reg(msc, MPAMF_AIDR);
>> -	u32 major = FIELD_GET(MPAMF_AIDR_ARCH_MAJOR_REV, aidr);
>> -	u32 minor = FIELD_GET(MPAMF_AIDR_ARCH_MINOR_REV, aidr);
>> +	u32 aidr, major, minor;
>>   
>> +	__mpam_read_reg(msc, MPAMF_AIDR, &aidr);
> 
> This will need updating to handle the error.  If you were to instead do
> the patches in the opposite order. So add return value to the outer
> most calls that is always 0 then work your way in it should end up
> as a fair bit less code churn.

But is it really better to review? You later say code lines are cheap, 
I'd say commits are cheap as well, but reviews are not. The idea was to 
allow separate, contained reviews, without forcing people to sit through 
all of this in one go - which you apparently did, so my condolences.
So yes, it's not the best to touch lines several times, but do we really 
care so much? Is it just about git blame?

Cheers,
Andre

> That update is in a later patch.
> 
>> +	major = FIELD_GET(MPAMF_AIDR_ARCH_MAJOR_REV, aidr);
>> +	minor = FIELD_GET(MPAMF_AIDR_ARCH_MINOR_REV, aidr);
>>   	/*
>>   	 * v0.0 and >v2.x aren't supported, but anything else should be backward
>>   	 * compatible to v0.1 or v1.0.