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@xxxxxxxxxxxxxx>
---
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 |
