The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
weren't selected by the specialty CPUs, Octeon and Loongson, which meant
it was possible to hit a weird state of:
MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n
This commit rectifies the issue by having CPU_MIPS64 be selected when
the missing Octeon or Loongson models are selected.
Cc: Thomas Bogendoerfer <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: George Cherian <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: Jiaxun Yang <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..3e0e8f1d2e82 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2118,7 +2118,7 @@ config CPU_MIPS32
config CPU_MIPS64
bool
default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
- CPU_MIPS64_R6
+ CPU_MIPS64_R6 || CPU_LOONGSON64 || CPU_CAVIUM_OCTEON
#
# These indicate the revision of the architecture
--
2.30.1
On Sat, 27 Feb 2021, Jason A. Donenfeld wrote:
> The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
> distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
That is not true. The purpose of these options is to identify MIPS64 and
MIPS32 ISA processors respectively (and the generic features these ISAs
imply). There are 64-bit and 32-bit MIPS processors which do not qualify,
specifically all MIPS I, MIPS II, MIPS III, and MIPS IV implementations.
> weren't selected by the specialty CPUs, Octeon and Loongson, which meant
> it was possible to hit a weird state of:
>
> MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n
This is a correct combination for MIPS III and MIPS IV processors.
> This commit rectifies the issue by having CPU_MIPS64 be selected when
> the missing Octeon or Loongson models are selected.
From the description and/or other options selected by CPU_LOONGSON64 and
CPU_CAVIUM_OCTEON I infer the change itself is correct, so you only need
to rewrite the change description.
Though overall it seems we have quite a mess here, several other CPUs,
such as at the very least CPU_XLR and CPU_XLP, do not select this option
either, and then we have say CPU_MIPSR2 that is selected by some CPUs
while being conditional on other ones. All this stuff asks for being
rewritten in a consistent manner.
In any case your change may have to be run-time verified though with the
respective processors.
Maciej
On Sat, Feb 27, 2021 at 2:41 PM Maciej W. Rozycki <[email protected]> wrote:
>
> On Sat, 27 Feb 2021, Jason A. Donenfeld wrote:
>
> > The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
> > distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
>
> That is not true. The purpose of these options is to identify MIPS64 and
> MIPS32 ISA processors respectively (and the generic features these ISAs
> imply). There are 64-bit and 32-bit MIPS processors which do not qualify,
> specifically all MIPS I, MIPS II, MIPS III, and MIPS IV implementations.
>
> > weren't selected by the specialty CPUs, Octeon and Loongson, which meant
> > it was possible to hit a weird state of:
> >
> > MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n
>
> This is a correct combination for MIPS III and MIPS IV processors.
>
> > This commit rectifies the issue by having CPU_MIPS64 be selected when
> > the missing Octeon or Loongson models are selected.
>
> From the description and/or other options selected by CPU_LOONGSON64 and
> CPU_CAVIUM_OCTEON I infer the change itself is correct, so you only need
> to rewrite the change description.
Indeed you're right. v2 on its way.
Jason
CPU_MIPS64 is supposed to be selected for CPUs that implement a revision
of the MIPS64 ISA. While it contains the generic ones, it forgot about
Octeon and Loongson in its list, which are indeed MIPS64 processors.
This commit adds these missing CPUs to the auto-selection list.
Cc: Maciej W. Rozycki <[email protected]>
Cc: Thomas Bogendoerfer <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: George Cherian <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: Jiaxun Yang <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..3e0e8f1d2e82 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2118,7 +2118,7 @@ config CPU_MIPS32
config CPU_MIPS64
bool
default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
- CPU_MIPS64_R6
+ CPU_MIPS64_R6 || CPU_LOONGSON64 || CPU_CAVIUM_OCTEON
#
# These indicate the revision of the architecture
--
2.30.1
On Sun, Feb 28, 2021 at 12:02:36AM +0100, Jason A. Donenfeld wrote:
> CPU_MIPS64 is supposed to be selected for CPUs that implement a revision
> of the MIPS64 ISA. While it contains the generic ones, it forgot about
> Octeon and Loongson in its list, which are indeed MIPS64 processors.
> This commit adds these missing CPUs to the auto-selection list.
>
> Cc: Maciej W. Rozycki <[email protected]>
> Cc: Thomas Bogendoerfer <[email protected]>
> Cc: Ralf Baechle <[email protected]>
> Cc: George Cherian <[email protected]>
> Cc: Huacai Chen <[email protected]>
> Cc: Jiaxun Yang <[email protected]>
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> ---
> arch/mips/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
Hey Thomas,
Would you mind sending this for 5.12 in an rc at some point, rather
than waiting for 5.13? I'd like to see this backported to 5.10 and 5.4
for OpenWRT.
Thanks,
Jason
On 3/3/21, Thomas Bogendoerfer <[email protected]> wrote:
> On Mon, Mar 01, 2021 at 05:27:46PM +0100, Jason A. Donenfeld wrote:
>> Hey Thomas,
>>
>> Would you mind sending this for 5.12 in an rc at some point, rather
>> than waiting for 5.13? I'd like to see this backported to 5.10 and 5.4
>> for OpenWRT.
>
> why is this so important for OpenWRT ? Just to select CRYPTO_POLY1305_MIPS
> ?
Yes. The performance boost on Octeon is significant for WireGuard users.
And it becomes incredibly frustrating to bifurcate packaging into
"mips64 where the config is right" vs "mips64 where the config is
borked." This saves us a lot of trouble.
Plus the patch is trivial.
On Mon, Mar 01, 2021 at 05:27:46PM +0100, Jason A. Donenfeld wrote:
> Hey Thomas,
>
> Would you mind sending this for 5.12 in an rc at some point, rather
> than waiting for 5.13? I'd like to see this backported to 5.10 and 5.4
> for OpenWRT.
why is this so important for OpenWRT ? Just to select CRYPTO_POLY1305_MIPS ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]