Searched hist:"76 ffb5785047b3924da20969eb3f658b363c20f0" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/arch/powerpc/include/asm/ |
| H A D | prom.h | diff 76ffb5785047b3924da20969eb3f658b363c20f0 Fri Nov 18 06:15:42 CST 2016 Michael Ellerman <mpe@ellerman.id.au> powerpc/prom: Switch to using structs for ibm_architecture_vec
Now that we've defined structures to describe each of the client
architecture vectors, we can use those to construct the value we pass to
firmware.
This avoids the tricks we previously played with the W() macro, allows
us to properly endian annotate fields, and should help to avoid bugs
introduced by failing to have the correct number of zero pad bytes
between fields.
It also means we can avoid hard coding IBM_ARCH_VEC_NRCORES_OFFSET in
order to update the max_cpus value and instead just set it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
| /openbmc/linux/arch/powerpc/kernel/ |
| H A D | prom_init.c | diff 76ffb5785047b3924da20969eb3f658b363c20f0 Fri Nov 18 06:15:42 CST 2016 Michael Ellerman <mpe@ellerman.id.au> powerpc/prom: Switch to using structs for ibm_architecture_vec
Now that we've defined structures to describe each of the client
architecture vectors, we can use those to construct the value we pass to
firmware.
This avoids the tricks we previously played with the W() macro, allows
us to properly endian annotate fields, and should help to avoid bugs
introduced by failing to have the correct number of zero pad bytes
between fields.
It also means we can avoid hard coding IBM_ARCH_VEC_NRCORES_OFFSET in
order to update the max_cpus value and instead just set it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|