[PATCH 3/3] arm: mach-imx: tzasc: convert to cpu_is_mx8xyz macros

[Stefan Kerkmann]

Hi Sascha,

On 27.02.24 09:44, Sascha Hauer wrote:
> On Mon, Feb 26, 2024 at 03:40:23PM +0100, Stefan Kerkmann wrote:
>> Instead of passing in configuration parameters at runtime we can utilize
>> the `cpu_is_mx8xyz` macro family to determine which bits should be set.
>>
>> As the tzasc driver is imx specific, all functions are prefixed with
>> `imx8m_` as well.
>>
>> Signed-off-by: Stefan Kerkmann <s.kerkmann at pengutronix.de>
>> ---
>>   arch/arm/mach-imx/atf.c   |  8 ++++----
>>   arch/arm/mach-imx/imx8m.c |  2 +-
>>   arch/arm/mach-imx/tzasc.c | 25 +++++--------------------
>>   include/mach/imx/tzasc.h  |  8 ++------
>>   4 files changed, 12 insertions(+), 31 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/atf.c b/arch/arm/mach-imx/atf.c
>> index e8060ebd95..9cbc38ef11 100644
>> --- a/arch/arm/mach-imx/atf.c
>> +++ b/arch/arm/mach-imx/atf.c
>> @@ -158,7 +158,7 @@ __noreturn void __imx8mm_load_and_start_image_via_tfa(void *bl33)
>>   		size_t bl32_size;
>>   		void *bl32_image;
>>   
>> -		imx8mm_tzc380_init();
>> +		imx8m_tzc380_init();
> 
> I am not so sure about this patch. So far the whole PBL is coded in the
> way that we inherently know the SoC type from the code path chosen.
> 
> This patch changes this. It doesn't really matter for this patch, but it
> sends a sign how we want to solve this in future.

Let's see if I can persuade you that this is a good thing :-).

> One implication of this patch is that cpu_is_mx() is a runtime decision,
> so code paths behind an unused cpu_is_mx() can't be discarded anymore.

My argument here is that the overhead in code size is probably neglect 
able in most cases, as most of the code paths are still discarded:

1. If there is only one ARCH selected e.g., `CONFIG_ARCH_IMX8MM` the 
`cpu_is_mx8mm()` macro is still evaluated at compile time. As the 
`__imx_cpu_type` variable is only assigned and never read it can be 
stripped away by the compiler/linker and become a nop.

2. Runtime evaluation is only selected if a second arch is enabled for 
the build. But even then the runtime decision is only compiled in for 
the two selected arches, as all other `cpu_is_xyz` macros still evaluate 
at compile time to false. So code paths that don't touch the selected 
arches will still be stripped.

> Another thing is that the usage of cpu_is() has the tendency to lead to
> cascades of if (cpu_is_x() || cpu_is_y() || cpu_is_z()) which is not
> paticularly nice to read.
> 

That is arguably subjective :-).

For me as a developer that is new to barebox, it was confusing to find 
two different styles of arch dependent code. I prefer the `cpu_is_xyz` 
style approach which is used in barebox proper much more.

In the case of the TZC380 driver the pseudo (as they are probably 
optimized away) runtime arguments to the init functions seem 
unnecessarily complicated, as does the approach to define aliases to the 
same function for all arches. The if style is clearer in intend as it 
keeps the distinction between the arches local to the parts that are 
actually different. Which is straight forward to read IMHO.

> Both are not really strong points, but on the other hand there's not
> much improvement in this patch, so I tend to not take it.
> 
>> -bool tzc380_is_enabled(void)
>> +bool imx8m_tzc380_is_enabled(void)
> 
> This change is good though as the function is clearly i.MX8 specific.
> 
> Sascha
> 

Cheers,
Stefan

-- 
Pengutronix e.K.                       | Stefan Kerkmann             |
Steuerwalder Str. 21                   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany              | Phone: +49-5121-206917-128  |
Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-9    |