Fix a few build warnings and one kconfig warning on SUPERH.
v2: add a previously-sent Kconfig patch
add a few more Cc's
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
[PATCH 1/3 v2] sh: fix kconfig unmet dependency warning for FRAME_POINTER
[PATCH 2/3 v2] sh: define __BIG_ENDIAN for math-emu
[PATCH 3/3 v2] sh: fix READ/WRITE redefinition warnings
arch/sh/Kconfig.debug | 1
arch/sh/include/asm/sfp-machine.h | 8 +++++
arch/sh/math-emu/math.c | 44 ++++++++++++++--------------
3 files changed, 31 insertions(+), 22 deletions(-)
FRAME_POINTER depends on DEBUG_KERNEL so DWARF_UNWINDER should
depend on DEBUG_KERNEL before selecting FRAME_POINTER.
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on [n]: DEBUG_KERNEL [=n] && (M68K || UML || SUPERH [=y]) || ARCH_WANT_FRAME_POINTERS [=n]
Selected by [y]:
- DWARF_UNWINDER [=y]
Fixes: bd353861c735 ("sh: dwarf unwinder support.")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
---
v2: drop Paul Mundt from Cc: list;
add this previously sent patch to the series;
add more Cc's;
arch/sh/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20210625.orig/arch/sh/Kconfig.debug
+++ linux-next-20210625/arch/sh/Kconfig.debug
@@ -57,6 +57,7 @@ config DUMP_CODE
config DWARF_UNWINDER
bool "Enable the DWARF unwinder for stacktraces"
+ depends on DEBUG_KERNEL
select FRAME_POINTER
default n
help
Fix this by defining both ENDIAN macros in
<asm/sfp-machine.h> so that they can be utilized in
<math-emu/soft-fp.h> according to the latter's comment:
/* Allow sfp-machine to have its own byte order definitions. */
(This is what is done in arch/nds32/include/asm/sfp-machine.h.)
This placates these build warnings:
In file included from ../arch/sh/math-emu/math.c:23:
../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
50 | #if __BYTE_ORDER == __BIG_ENDIAN
In file included from ../arch/sh/math-emu/math.c:24:
../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
59 | #if __BYTE_ORDER == __BIG_ENDIAN
Fixes: 4b565680d163 ("sh: math-emu support")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: John Paul Adrian Glaubitz <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
---
v2: use same preprocessor method that nds32 does;
add Geert's Reviewed-by;
renumber patches;
add more Cc's;
arch/sh/include/asm/sfp-machine.h | 8 ++++++++
1 file changed, 8 insertions(+)
--- linux-next-20210625.orig/arch/sh/include/asm/sfp-machine.h
+++ linux-next-20210625/arch/sh/include/asm/sfp-machine.h
@@ -13,6 +13,14 @@
#ifndef _SFP_MACHINE_H
#define _SFP_MACHINE_H
+#ifdef __BIG_ENDIAN__
+#define __BYTE_ORDER __BIG_ENDIAN
+#define __LITTLE_ENDIAN 0
+#else
+#define __BYTE_ORDER __LITTLE_ENDIAN
+#define __BIG_ENDIAN 0
+#endif
+
#define _FP_W_TYPE_SIZE 32
#define _FP_W_TYPE unsigned long
#define _FP_WS_TYPE signed long
kernel.h defines READ and WRITE, so rename the SH math-emu macros
to MREAD and MWRITE.
Fixes these warnings:
../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
In file included from ../arch/sh/math-emu/math.c:10:
../include/linux/kernel.h:37: note: this is the location of the previous definition
37 | #define WRITE 1
../arch/sh/math-emu/math.c:55: warning: "READ" redefined
55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
In file included from ../arch/sh/math-emu/math.c:10:
../include/linux/kernel.h:36: note: this is the location of the previous definition
36 | #define READ 0
Fixes: 4b565680d163 ("sh: math-emu support")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Cc: Takashi YOSHII <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
---
v2: renumber patches, otherwise no change;
arch/sh/math-emu/math.c | 44 +++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 22 deletions(-)
--- linux-next-20210625.orig/arch/sh/math-emu/math.c
+++ linux-next-20210625/arch/sh/math-emu/math.c
@@ -51,8 +51,8 @@
#define Rn (regs->regs[n])
#define Rm (regs->regs[m])
-#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
-#define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
+#define MWRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
+#define MREAD(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
#define PACK_S(r,f) FP_PACK_SP(&r,f)
#define UNPACK_S(f,r) FP_UNPACK_SP(f,&r)
@@ -157,11 +157,11 @@ fmov_idx_reg(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(n);
- READ(FRn, Rm + R0 + 4);
+ MREAD(FRn, Rm + R0 + 4);
n++;
- READ(FRn, Rm + R0);
+ MREAD(FRn, Rm + R0);
} else {
- READ(FRn, Rm + R0);
+ MREAD(FRn, Rm + R0);
}
return 0;
@@ -173,11 +173,11 @@ fmov_mem_reg(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(n);
- READ(FRn, Rm + 4);
+ MREAD(FRn, Rm + 4);
n++;
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
} else {
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
}
return 0;
@@ -189,12 +189,12 @@ fmov_inc_reg(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(n);
- READ(FRn, Rm + 4);
+ MREAD(FRn, Rm + 4);
n++;
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
Rm += 8;
} else {
- READ(FRn, Rm);
+ MREAD(FRn, Rm);
Rm += 4;
}
@@ -207,11 +207,11 @@ fmov_reg_idx(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(m);
- WRITE(FRm, Rn + R0 + 4);
+ MWRITE(FRm, Rn + R0 + 4);
m++;
- WRITE(FRm, Rn + R0);
+ MWRITE(FRm, Rn + R0);
} else {
- WRITE(FRm, Rn + R0);
+ MWRITE(FRm, Rn + R0);
}
return 0;
@@ -223,11 +223,11 @@ fmov_reg_mem(struct sh_fpu_soft_struct *
{
if (FPSCR_SZ) {
FMOV_EXT(m);
- WRITE(FRm, Rn + 4);
+ MWRITE(FRm, Rn + 4);
m++;
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
} else {
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
}
return 0;
@@ -240,12 +240,12 @@ fmov_reg_dec(struct sh_fpu_soft_struct *
if (FPSCR_SZ) {
FMOV_EXT(m);
Rn -= 8;
- WRITE(FRm, Rn + 4);
+ MWRITE(FRm, Rn + 4);
m++;
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
} else {
Rn -= 4;
- WRITE(FRm, Rn);
+ MWRITE(FRm, Rn);
}
return 0;
@@ -445,11 +445,11 @@ id_sys(struct sh_fpu_soft_struct *fregs,
case 0x4052:
case 0x4062:
Rn -= 4;
- WRITE(*reg, Rn);
+ MWRITE(*reg, Rn);
break;
case 0x4056:
case 0x4066:
- READ(*reg, Rn);
+ MREAD(*reg, Rn);
Rn += 4;
break;
default:
Hi Randy!
On 6/28/21 12:05 AM, Randy Dunlap wrote:
> Fix a few build warnings and one kconfig warning on SUPERH.
>
> v2: add a previously-sent Kconfig patch
> add a few more Cc's
>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Cc: John Paul Adrian Glaubitz <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
>
> [PATCH 1/3 v2] sh: fix kconfig unmet dependency warning for FRAME_POINTER
> [PATCH 2/3 v2] sh: define __BIG_ENDIAN for math-emu
> [PATCH 3/3 v2] sh: fix READ/WRITE redefinition warnings
>
> arch/sh/Kconfig.debug | 1
> arch/sh/include/asm/sfp-machine.h | 8 +++++
> arch/sh/math-emu/math.c | 44 ++++++++++++++--------------
> 3 files changed, 31 insertions(+), 22 deletions(-)
I'll test these tomorrow on my SH-7785LCR board. Would it be possible to queue
them up for linux-next after verification?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/27/21 3:26 PM, John Paul Adrian Glaubitz wrote:
> Hi Randy!
>
> On 6/28/21 12:05 AM, Randy Dunlap wrote:
>> Fix a few build warnings and one kconfig warning on SUPERH.
>>
>> v2: add a previously-sent Kconfig patch
>> add a few more Cc's
>>
>> Cc: Yoshinori Sato <[email protected]>
>> Cc: Rich Felker <[email protected]>
>> Cc: [email protected]
>> Cc: John Paul Adrian Glaubitz <[email protected]>
>> Cc: Geert Uytterhoeven <[email protected]>
>>
>> [PATCH 1/3 v2] sh: fix kconfig unmet dependency warning for FRAME_POINTER
>> [PATCH 2/3 v2] sh: define __BIG_ENDIAN for math-emu
>> [PATCH 3/3 v2] sh: fix READ/WRITE redefinition warnings
>>
>> arch/sh/Kconfig.debug | 1
>> arch/sh/include/asm/sfp-machine.h | 8 +++++
>> arch/sh/math-emu/math.c | 44 ++++++++++++++--------------
>> 3 files changed, 31 insertions(+), 22 deletions(-)
>
> I'll test these tomorrow on my SH-7785LCR board. Would it be possible to queue
> them up for linux-next after verification?
Thanks. Hopefully they will be queued and put into linux-next,
but that's up to the arch/sh/ maintainers, and I haven't heard
from them lately. :(
--
~Randy
Hi Randy!
On 6/28/21 12:30 AM, Randy Dunlap wrote:
>>> [PATCH 1/3 v2] sh: fix kconfig unmet dependency warning for FRAME_POINTER
>>> [PATCH 2/3 v2] sh: define __BIG_ENDIAN for math-emu
>>> [PATCH 3/3 v2] sh: fix READ/WRITE redefinition warnings
>>>
>>> arch/sh/Kconfig.debug | 1
>>> arch/sh/include/asm/sfp-machine.h | 8 +++++
>>> arch/sh/math-emu/math.c | 44 ++++++++++++++--------------
>>> 3 files changed, 31 insertions(+), 22 deletions(-)
>>
>> I'll test these tomorrow on my SH-7785LCR board. Would it be possible to queue
>> them up for linux-next after verification?
>
> Thanks. Hopefully they will be queued and put into linux-next,
> but that's up to the arch/sh/ maintainers, and I haven't heard
> from them lately. :(
Whoops, I was meant to direct the second part to Rich :-).
Rich is still around and he reviews and merges patches. Sometimes he is a bit
busy with other things, so response times can sometimes be a bit delayed.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, Jun 28, 2021 at 12:05 AM Randy Dunlap <[email protected]> wrote:
> FRAME_POINTER depends on DEBUG_KERNEL so DWARF_UNWINDER should
> depend on DEBUG_KERNEL before selecting FRAME_POINTER.
>
> WARNING: unmet direct dependencies detected for FRAME_POINTER
> Depends on [n]: DEBUG_KERNEL [=n] && (M68K || UML || SUPERH [=y]) || ARCH_WANT_FRAME_POINTERS [=n]
> Selected by [y]:
> - DWARF_UNWINDER [=y]
>
> Fixes: bd353861c735 ("sh: dwarf unwinder support.")
> Signed-off-by: Randy Dunlap <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Jun 28, 2021 at 12:05 AM Randy Dunlap <[email protected]> wrote:
> kernel.h defines READ and WRITE, so rename the SH math-emu macros
> to MREAD and MWRITE.
>
> Fixes these warnings:
>
> ../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
> 54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> In file included from ../arch/sh/math-emu/math.c:10:
> ../include/linux/kernel.h:37: note: this is the location of the previous definition
> 37 | #define WRITE 1
> ../arch/sh/math-emu/math.c:55: warning: "READ" redefined
> 55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> In file included from ../arch/sh/math-emu/math.c:10:
> ../include/linux/kernel.h:36: note: this is the location of the previous definition
> 36 | #define READ 0
>
> Fixes: 4b565680d163 ("sh: math-emu support")
> Signed-off-by: Randy Dunlap <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hello!
On 6/28/21 12:26 AM, John Paul Adrian Glaubitz wrote:
>> arch/sh/Kconfig.debug | 1
>> arch/sh/include/asm/sfp-machine.h | 8 +++++
>> arch/sh/math-emu/math.c | 44 ++++++++++++++--------------
>> 3 files changed, 31 insertions(+), 22 deletions(-)
>
> I'll test these tomorrow on my SH-7785LCR board. Would it be possible to queue
> them up for linux-next after verification?
Just as a heads-up: My fast EPYC server for kernel cross-compilation is currently down,
so I'll have to set up a new machine at SUSE tomorrow for that purpose. Hope to be able
to test the kernel after that.
Sorry for the delay, the other server is currently down due to an A/C failure at the university.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/28/21 12:05 AM, Randy Dunlap wrote:
> FRAME_POINTER depends on DEBUG_KERNEL so DWARF_UNWINDER should
> depend on DEBUG_KERNEL before selecting FRAME_POINTER.
>
> WARNING: unmet direct dependencies detected for FRAME_POINTER
> Depends on [n]: DEBUG_KERNEL [=n] && (M68K || UML || SUPERH [=y]) || ARCH_WANT_FRAME_POINTERS [=n]
> Selected by [y]:
> - DWARF_UNWINDER [=y]
>
> Fixes: bd353861c735 ("sh: dwarf unwinder support.")
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Matt Fleming <[email protected]>
> Cc: Matt Fleming <[email protected]>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Cc: John Paul Adrian Glaubitz <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> ---
> v2: drop Paul Mundt from Cc: list;
> add this previously sent patch to the series;
> add more Cc's;
>
> arch/sh/Kconfig.debug | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20210625.orig/arch/sh/Kconfig.debug
> +++ linux-next-20210625/arch/sh/Kconfig.debug
> @@ -57,6 +57,7 @@ config DUMP_CODE
>
> config DWARF_UNWINDER
> bool "Enable the DWARF unwinder for stacktraces"
> + depends on DEBUG_KERNEL
> select FRAME_POINTER
> default n
> help
>
Boot-tested on my SH-7785LCR without any issues (as expected).
Tested-by: John Paul Adrian Glaubitz <[email protected]>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/28/21 12:05 AM, Randy Dunlap wrote:
> Fix this by defining both ENDIAN macros in
> <asm/sfp-machine.h> so that they can be utilized in
> <math-emu/soft-fp.h> according to the latter's comment:
> /* Allow sfp-machine to have its own byte order definitions. */
>
> (This is what is done in arch/nds32/include/asm/sfp-machine.h.)
>
> This placates these build warnings:
>
> In file included from ../arch/sh/math-emu/math.c:23:
> ../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
> 50 | #if __BYTE_ORDER == __BIG_ENDIAN
> In file included from ../arch/sh/math-emu/math.c:24:
> ../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
> 59 | #if __BYTE_ORDER == __BIG_ENDIAN
>
> Fixes: 4b565680d163 ("sh: math-emu support")
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Cc: John Paul Adrian Glaubitz <[email protected]>
> Reviewed-by: Geert Uytterhoeven <[email protected]>
> ---
> v2: use same preprocessor method that nds32 does;
> add Geert's Reviewed-by;
> renumber patches;
> add more Cc's;
>
> arch/sh/include/asm/sfp-machine.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> --- linux-next-20210625.orig/arch/sh/include/asm/sfp-machine.h
> +++ linux-next-20210625/arch/sh/include/asm/sfp-machine.h
> @@ -13,6 +13,14 @@
> #ifndef _SFP_MACHINE_H
> #define _SFP_MACHINE_H
>
> +#ifdef __BIG_ENDIAN__
> +#define __BYTE_ORDER __BIG_ENDIAN
> +#define __LITTLE_ENDIAN 0
> +#else
> +#define __BYTE_ORDER __LITTLE_ENDIAN
> +#define __BIG_ENDIAN 0
> +#endif
> +
> #define _FP_W_TYPE_SIZE 32
> #define _FP_W_TYPE unsigned long
> #define _FP_WS_TYPE signed long
>
Boot-tested on my SH-7785LCR without any issues.
Tested-by: John Paul Adrian Glaubitz <[email protected]>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/28/21 12:05 AM, Randy Dunlap wrote:
> kernel.h defines READ and WRITE, so rename the SH math-emu macros
> to MREAD and MWRITE.
>
> Fixes these warnings:
>
> ../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
> 54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> In file included from ../arch/sh/math-emu/math.c:10:
> ../include/linux/kernel.h:37: note: this is the location of the previous definition
> 37 | #define WRITE 1
> ../arch/sh/math-emu/math.c:55: warning: "READ" redefined
> 55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> In file included from ../arch/sh/math-emu/math.c:10:
> ../include/linux/kernel.h:36: note: this is the location of the previous definition
> 36 | #define READ 0
>
> Fixes: 4b565680d163 ("sh: math-emu support")
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Cc: Takashi YOSHII <[email protected]>
> Cc: John Paul Adrian Glaubitz <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> ---
> v2: renumber patches, otherwise no change;
>
> arch/sh/math-emu/math.c | 44 +++++++++++++++++++-------------------
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> --- linux-next-20210625.orig/arch/sh/math-emu/math.c
> +++ linux-next-20210625/arch/sh/math-emu/math.c
> @@ -51,8 +51,8 @@
> #define Rn (regs->regs[n])
> #define Rm (regs->regs[m])
>
> -#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> -#define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> +#define MWRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> +#define MREAD(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>
> #define PACK_S(r,f) FP_PACK_SP(&r,f)
> #define UNPACK_S(f,r) FP_UNPACK_SP(f,&r)
> @@ -157,11 +157,11 @@ fmov_idx_reg(struct sh_fpu_soft_struct *
> {
> if (FPSCR_SZ) {
> FMOV_EXT(n);
> - READ(FRn, Rm + R0 + 4);
> + MREAD(FRn, Rm + R0 + 4);
> n++;
> - READ(FRn, Rm + R0);
> + MREAD(FRn, Rm + R0);
> } else {
> - READ(FRn, Rm + R0);
> + MREAD(FRn, Rm + R0);
> }
>
> return 0;
> @@ -173,11 +173,11 @@ fmov_mem_reg(struct sh_fpu_soft_struct *
> {
> if (FPSCR_SZ) {
> FMOV_EXT(n);
> - READ(FRn, Rm + 4);
> + MREAD(FRn, Rm + 4);
> n++;
> - READ(FRn, Rm);
> + MREAD(FRn, Rm);
> } else {
> - READ(FRn, Rm);
> + MREAD(FRn, Rm);
> }
>
> return 0;
> @@ -189,12 +189,12 @@ fmov_inc_reg(struct sh_fpu_soft_struct *
> {
> if (FPSCR_SZ) {
> FMOV_EXT(n);
> - READ(FRn, Rm + 4);
> + MREAD(FRn, Rm + 4);
> n++;
> - READ(FRn, Rm);
> + MREAD(FRn, Rm);
> Rm += 8;
> } else {
> - READ(FRn, Rm);
> + MREAD(FRn, Rm);
> Rm += 4;
> }
>
> @@ -207,11 +207,11 @@ fmov_reg_idx(struct sh_fpu_soft_struct *
> {
> if (FPSCR_SZ) {
> FMOV_EXT(m);
> - WRITE(FRm, Rn + R0 + 4);
> + MWRITE(FRm, Rn + R0 + 4);
> m++;
> - WRITE(FRm, Rn + R0);
> + MWRITE(FRm, Rn + R0);
> } else {
> - WRITE(FRm, Rn + R0);
> + MWRITE(FRm, Rn + R0);
> }
>
> return 0;
> @@ -223,11 +223,11 @@ fmov_reg_mem(struct sh_fpu_soft_struct *
> {
> if (FPSCR_SZ) {
> FMOV_EXT(m);
> - WRITE(FRm, Rn + 4);
> + MWRITE(FRm, Rn + 4);
> m++;
> - WRITE(FRm, Rn);
> + MWRITE(FRm, Rn);
> } else {
> - WRITE(FRm, Rn);
> + MWRITE(FRm, Rn);
> }
>
> return 0;
> @@ -240,12 +240,12 @@ fmov_reg_dec(struct sh_fpu_soft_struct *
> if (FPSCR_SZ) {
> FMOV_EXT(m);
> Rn -= 8;
> - WRITE(FRm, Rn + 4);
> + MWRITE(FRm, Rn + 4);
> m++;
> - WRITE(FRm, Rn);
> + MWRITE(FRm, Rn);
> } else {
> Rn -= 4;
> - WRITE(FRm, Rn);
> + MWRITE(FRm, Rn);
> }
>
> return 0;
> @@ -445,11 +445,11 @@ id_sys(struct sh_fpu_soft_struct *fregs,
> case 0x4052:
> case 0x4062:
> Rn -= 4;
> - WRITE(*reg, Rn);
> + MWRITE(*reg, Rn);
> break;
> case 0x4056:
> case 0x4066:
> - READ(*reg, Rn);
> + MREAD(*reg, Rn);
> Rn += 4;
> break;
> default:
>
This one no longer applies to Linus' tree:
glaubitz@node54:/data/home/glaubitz/linux> git am ../sh-patches-2021/\[PATCH\ 3_3\ v2\]\ sh\:\ fix\ READ_WRITE\ redefinition\ warnings.eml
Applying: sh: fix READ/WRITE redefinition warnings
error: patch failed: arch/sh/math-emu/math.c:51
error: arch/sh/math-emu/math.c: patch does not apply
Patch failed at 0001 sh: fix READ/WRITE redefinition warnings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
glaubitz@node54:/data/home/glaubitz/linux>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
On Wed, Jun 30, 2021 at 11:36 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 6/28/21 12:05 AM, Randy Dunlap wrote:
> > kernel.h defines READ and WRITE, so rename the SH math-emu macros
> > to MREAD and MWRITE.
> >
> > Fixes these warnings:
> >
> > ../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
> > 54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> > In file included from ../arch/sh/math-emu/math.c:10:
> > ../include/linux/kernel.h:37: note: this is the location of the previous definition
> > 37 | #define WRITE 1
> > ../arch/sh/math-emu/math.c:55: warning: "READ" redefined
> > 55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> > In file included from ../arch/sh/math-emu/math.c:10:
> > ../include/linux/kernel.h:36: note: this is the location of the previous definition
> > 36 | #define READ 0
> >
> > Fixes: 4b565680d163 ("sh: math-emu support")
> > Signed-off-by: Randy Dunlap <[email protected]>
> This one no longer applies to Linus' tree:
Worked fine for me.
Ah, Linus tree still doesn't have b1deeeb93933d390[1] ("sh: fix
trivial misannotations"), which has been lingering in sh/for-next
since the beginning or March.
[1] Note to Gmail: No, I don't want to correct this to "b1de b93933d390".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 6/30/21 2:36 AM, John Paul Adrian Glaubitz wrote:
> On 6/28/21 12:05 AM, Randy Dunlap wrote:
>> kernel.h defines READ and WRITE, so rename the SH math-emu macros
>> to MREAD and MWRITE.
>>
>> Fixes these warnings:
>>
>> ../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
>> 54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>> In file included from ../arch/sh/math-emu/math.c:10:
>> ../include/linux/kernel.h:37: note: this is the location of the previous definition
>> 37 | #define WRITE 1
>> ../arch/sh/math-emu/math.c:55: warning: "READ" redefined
>> 55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>> In file included from ../arch/sh/math-emu/math.c:10:
>> ../include/linux/kernel.h:36: note: this is the location of the previous definition
>> 36 | #define READ 0
>>
>> Fixes: 4b565680d163 ("sh: math-emu support")
>> Signed-off-by: Randy Dunlap <[email protected]>
>> Cc: Yoshinori Sato <[email protected]>
>> Cc: Rich Felker <[email protected]>
>> Cc: [email protected]
>> Cc: Takashi YOSHII <[email protected]>
>> Cc: John Paul Adrian Glaubitz <[email protected]>
>> Cc: Geert Uytterhoeven <[email protected]>
>> ---
>> v2: renumber patches, otherwise no change;
>>
>> arch/sh/math-emu/math.c | 44 +++++++++++++++++++-------------------
>> 1 file changed, 22 insertions(+), 22 deletions(-)
>>
>> --- linux-next-20210625.orig/arch/sh/math-emu/math.c
>> +++ linux-next-20210625/arch/sh/math-emu/math.c
>> @@ -51,8 +51,8 @@
>> #define Rn (regs->regs[n])
>> #define Rm (regs->regs[m])
>>
>> -#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>> -#define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>> +#define MWRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>> +#define MREAD(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>
>> #define PACK_S(r,f) FP_PACK_SP(&r,f)
>> #define UNPACK_S(f,r) FP_UNPACK_SP(f,&r)
>> @@ -157,11 +157,11 @@ fmov_idx_reg(struct sh_fpu_soft_struct *
>> {
>> if (FPSCR_SZ) {
>> FMOV_EXT(n);
>> - READ(FRn, Rm + R0 + 4);
>> + MREAD(FRn, Rm + R0 + 4);
>> n++;
>> - READ(FRn, Rm + R0);
>> + MREAD(FRn, Rm + R0);
>> } else {
>> - READ(FRn, Rm + R0);
>> + MREAD(FRn, Rm + R0);
>> }
>>
>> return 0;
>> @@ -173,11 +173,11 @@ fmov_mem_reg(struct sh_fpu_soft_struct *
>> {
>> if (FPSCR_SZ) {
>> FMOV_EXT(n);
>> - READ(FRn, Rm + 4);
>> + MREAD(FRn, Rm + 4);
>> n++;
>> - READ(FRn, Rm);
>> + MREAD(FRn, Rm);
>> } else {
>> - READ(FRn, Rm);
>> + MREAD(FRn, Rm);
>> }
>>
>> return 0;
>> @@ -189,12 +189,12 @@ fmov_inc_reg(struct sh_fpu_soft_struct *
>> {
>> if (FPSCR_SZ) {
>> FMOV_EXT(n);
>> - READ(FRn, Rm + 4);
>> + MREAD(FRn, Rm + 4);
>> n++;
>> - READ(FRn, Rm);
>> + MREAD(FRn, Rm);
>> Rm += 8;
>> } else {
>> - READ(FRn, Rm);
>> + MREAD(FRn, Rm);
>> Rm += 4;
>> }
>>
>> @@ -207,11 +207,11 @@ fmov_reg_idx(struct sh_fpu_soft_struct *
>> {
>> if (FPSCR_SZ) {
>> FMOV_EXT(m);
>> - WRITE(FRm, Rn + R0 + 4);
>> + MWRITE(FRm, Rn + R0 + 4);
>> m++;
>> - WRITE(FRm, Rn + R0);
>> + MWRITE(FRm, Rn + R0);
>> } else {
>> - WRITE(FRm, Rn + R0);
>> + MWRITE(FRm, Rn + R0);
>> }
>>
>> return 0;
>> @@ -223,11 +223,11 @@ fmov_reg_mem(struct sh_fpu_soft_struct *
>> {
>> if (FPSCR_SZ) {
>> FMOV_EXT(m);
>> - WRITE(FRm, Rn + 4);
>> + MWRITE(FRm, Rn + 4);
>> m++;
>> - WRITE(FRm, Rn);
>> + MWRITE(FRm, Rn);
>> } else {
>> - WRITE(FRm, Rn);
>> + MWRITE(FRm, Rn);
>> }
>>
>> return 0;
>> @@ -240,12 +240,12 @@ fmov_reg_dec(struct sh_fpu_soft_struct *
>> if (FPSCR_SZ) {
>> FMOV_EXT(m);
>> Rn -= 8;
>> - WRITE(FRm, Rn + 4);
>> + MWRITE(FRm, Rn + 4);
>> m++;
>> - WRITE(FRm, Rn);
>> + MWRITE(FRm, Rn);
>> } else {
>> Rn -= 4;
>> - WRITE(FRm, Rn);
>> + MWRITE(FRm, Rn);
>> }
>>
>> return 0;
>> @@ -445,11 +445,11 @@ id_sys(struct sh_fpu_soft_struct *fregs,
>> case 0x4052:
>> case 0x4062:
>> Rn -= 4;
>> - WRITE(*reg, Rn);
>> + MWRITE(*reg, Rn);
>> break;
>> case 0x4056:
>> case 0x4066:
>> - READ(*reg, Rn);
>> + MREAD(*reg, Rn);
>> Rn += 4;
>> break;
>> default:
>>
>
> This one no longer applies to Linus' tree:
>
> glaubitz@node54:/data/home/glaubitz/linux> git am ../sh-patches-2021/\[PATCH\ 3_3\ v2\]\ sh\:\ fix\ READ_WRITE\ redefinition\ warnings.eml
> Applying: sh: fix READ/WRITE redefinition warnings
> error: patch failed: arch/sh/math-emu/math.c:51
> error: arch/sh/math-emu/math.c: patch does not apply
> Patch failed at 0001 sh: fix READ/WRITE redefinition warnings
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> glaubitz@node54:/data/home/glaubitz/linux>
OK. Thanks for all of the testing.
--
~Randy
On 6/30/21 9:33 PM, Randy Dunlap wrote:
> On 6/30/21 2:36 AM, John Paul Adrian Glaubitz wrote:
>> On 6/28/21 12:05 AM, Randy Dunlap wrote:
>>> kernel.h defines READ and WRITE, so rename the SH math-emu macros
>>> to MREAD and MWRITE.
>>>
>>> Fixes these warnings:
>>>
>>> ../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
>>> 54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>> In file included from ../arch/sh/math-emu/math.c:10:
>>> ../include/linux/kernel.h:37: note: this is the location of the previous definition
>>> 37 | #define WRITE 1
>>> ../arch/sh/math-emu/math.c:55: warning: "READ" redefined
>>> 55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>> In file included from ../arch/sh/math-emu/math.c:10:
>>> ../include/linux/kernel.h:36: note: this is the location of the previous definition
>>> 36 | #define READ 0
>>>
>>> Fixes: 4b565680d163 ("sh: math-emu support")
>>> Signed-off-by: Randy Dunlap <[email protected]>
>>> Cc: Yoshinori Sato <[email protected]>
>>> Cc: Rich Felker <[email protected]>
>>> Cc: [email protected]
>>> Cc: Takashi YOSHII <[email protected]>
>>> Cc: John Paul Adrian Glaubitz <[email protected]>
>>> Cc: Geert Uytterhoeven <[email protected]>
>>> ---
>>> v2: renumber patches, otherwise no change;
>>>
>>> arch/sh/math-emu/math.c | 44 +++++++++++++++++++-------------------
>>> 1 file changed, 22 insertions(+), 22 deletions(-)
>>>
>>> --- linux-next-20210625.orig/arch/sh/math-emu/math.c
>>> +++ linux-next-20210625/arch/sh/math-emu/math.c
>>> @@ -51,8 +51,8 @@
>>> #define Rn (regs->regs[n])
>>> #define Rm (regs->regs[m])
>>>
>>> -#define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>> -#define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>> +#define MWRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>> +#define MREAD(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
>>>
>>> #define PACK_S(r,f) FP_PACK_SP(&r,f)
>>> #define UNPACK_S(f,r) FP_UNPACK_SP(f,&r)
>>> @@ -157,11 +157,11 @@ fmov_idx_reg(struct sh_fpu_soft_struct *
>>> {
>>> if (FPSCR_SZ) {
>>> FMOV_EXT(n);
>>> - READ(FRn, Rm + R0 + 4);
>>> + MREAD(FRn, Rm + R0 + 4);
>>> n++;
>>> - READ(FRn, Rm + R0);
>>> + MREAD(FRn, Rm + R0);
>>> } else {
>>> - READ(FRn, Rm + R0);
>>> + MREAD(FRn, Rm + R0);
>>> }
>>>
>>> return 0;
>>> @@ -173,11 +173,11 @@ fmov_mem_reg(struct sh_fpu_soft_struct *
>>> {
>>> if (FPSCR_SZ) {
>>> FMOV_EXT(n);
>>> - READ(FRn, Rm + 4);
>>> + MREAD(FRn, Rm + 4);
>>> n++;
>>> - READ(FRn, Rm);
>>> + MREAD(FRn, Rm);
>>> } else {
>>> - READ(FRn, Rm);
>>> + MREAD(FRn, Rm);
>>> }
>>>
>>> return 0;
>>> @@ -189,12 +189,12 @@ fmov_inc_reg(struct sh_fpu_soft_struct *
>>> {
>>> if (FPSCR_SZ) {
>>> FMOV_EXT(n);
>>> - READ(FRn, Rm + 4);
>>> + MREAD(FRn, Rm + 4);
>>> n++;
>>> - READ(FRn, Rm);
>>> + MREAD(FRn, Rm);
>>> Rm += 8;
>>> } else {
>>> - READ(FRn, Rm);
>>> + MREAD(FRn, Rm);
>>> Rm += 4;
>>> }
>>>
>>> @@ -207,11 +207,11 @@ fmov_reg_idx(struct sh_fpu_soft_struct *
>>> {
>>> if (FPSCR_SZ) {
>>> FMOV_EXT(m);
>>> - WRITE(FRm, Rn + R0 + 4);
>>> + MWRITE(FRm, Rn + R0 + 4);
>>> m++;
>>> - WRITE(FRm, Rn + R0);
>>> + MWRITE(FRm, Rn + R0);
>>> } else {
>>> - WRITE(FRm, Rn + R0);
>>> + MWRITE(FRm, Rn + R0);
>>> }
>>>
>>> return 0;
>>> @@ -223,11 +223,11 @@ fmov_reg_mem(struct sh_fpu_soft_struct *
>>> {
>>> if (FPSCR_SZ) {
>>> FMOV_EXT(m);
>>> - WRITE(FRm, Rn + 4);
>>> + MWRITE(FRm, Rn + 4);
>>> m++;
>>> - WRITE(FRm, Rn);
>>> + MWRITE(FRm, Rn);
>>> } else {
>>> - WRITE(FRm, Rn);
>>> + MWRITE(FRm, Rn);
>>> }
>>>
>>> return 0;
>>> @@ -240,12 +240,12 @@ fmov_reg_dec(struct sh_fpu_soft_struct *
>>> if (FPSCR_SZ) {
>>> FMOV_EXT(m);
>>> Rn -= 8;
>>> - WRITE(FRm, Rn + 4);
>>> + MWRITE(FRm, Rn + 4);
>>> m++;
>>> - WRITE(FRm, Rn);
>>> + MWRITE(FRm, Rn);
>>> } else {
>>> Rn -= 4;
>>> - WRITE(FRm, Rn);
>>> + MWRITE(FRm, Rn);
>>> }
>>>
>>> return 0;
>>> @@ -445,11 +445,11 @@ id_sys(struct sh_fpu_soft_struct *fregs,
>>> case 0x4052:
>>> case 0x4062:
>>> Rn -= 4;
>>> - WRITE(*reg, Rn);
>>> + MWRITE(*reg, Rn);
>>> break;
>>> case 0x4056:
>>> case 0x4066:
>>> - READ(*reg, Rn);
>>> + MREAD(*reg, Rn);
>>> Rn += 4;
>>> break;
>>> default:
>>>
>>
>> This one no longer applies to Linus' tree:
>>
>> glaubitz@node54:/data/home/glaubitz/linux> git am ../sh-patches-2021/\[PATCH\ 3_3\ v2\]\ sh\:\ fix\ READ_WRITE\ redefinition\ warnings.eml
>> Applying: sh: fix READ/WRITE redefinition warnings
>> error: patch failed: arch/sh/math-emu/math.c:51
>> error: arch/sh/math-emu/math.c: patch does not apply
>> Patch failed at 0001 sh: fix READ/WRITE redefinition warnings
>> hint: Use 'git am --show-current-patch=diff' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>> glaubitz@node54:/data/home/glaubitz/linux>
>
> OK. Thanks for all of the testing.
I'll report back with the other patch applied that Geert mentioned from linux-next before this one.
FWIW, there are some warnings when building the SH-7785LCR configuration:
In file included from ./arch/sh/include/asm/hw_irq.h:6,
from ./include/linux/irq.h:591,
from ./include/asm-generic/hardirq.h:17,
from ./arch/sh/include/asm/hardirq.h:9,
from ./include/linux/hardirq.h:11,
from ./include/linux/interrupt.h:11,
from ./include/linux/serial_core.h:13,
from ./include/linux/serial_sci.h:6,
from arch/sh/kernel/cpu/sh4a/setup-sh7785.c:10:
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:478:8: note: in expansion of macro 'DECLARE_INTC_DESC'
478 | static DECLARE_INTC_DESC(intc_desc, "sh7785", vectors, groups,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:107:34: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:478:8: note: in expansion of macro 'DECLARE_INTC_DESC'
478 | static DECLARE_INTC_DESC(intc_desc, "sh7785", vectors, groups,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:132:15: note: in expansion of macro 'INTC_HW_DESC'
132 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:503:8: note: in expansion of macro 'DECLARE_INTC_DESC_ACK'
503 | static DECLARE_INTC_DESC_ACK(intc_desc_irq0123, "sh7785-irq0123",
| ^~~~~~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:132:15: note: in expansion of macro 'INTC_HW_DESC'
132 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:507:8: note: in expansion of macro 'DECLARE_INTC_DESC_ACK'
507 | static DECLARE_INTC_DESC_ACK(intc_desc_irq4567, "sh7785-irq4567",
| ^~~~~~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:535:8: note: in expansion of macro 'DECLARE_INTC_DESC'
535 | static DECLARE_INTC_DESC(intc_desc_irl0123, "sh7785-irl0123", vectors_irl0123,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:106:33: note: in expansion of macro '_INTC_ARRAY'
106 | _INTC_ARRAY(mask_regs), _INTC_ARRAY(prio_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:535:8: note: in expansion of macro 'DECLARE_INTC_DESC'
535 | static DECLARE_INTC_DESC(intc_desc_irl0123, "sh7785-irl0123", vectors_irl0123,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:535:8: note: in expansion of macro 'DECLARE_INTC_DESC'
535 | static DECLARE_INTC_DESC(intc_desc_irl0123, "sh7785-irl0123", vectors_irl0123,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:107:34: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:535:8: note: in expansion of macro 'DECLARE_INTC_DESC'
535 | static DECLARE_INTC_DESC(intc_desc_irl0123, "sh7785-irl0123", vectors_irl0123,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:105:31: note: in expansion of macro '_INTC_ARRAY'
105 | _INTC_ARRAY(vectors), _INTC_ARRAY(groups), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:538:8: note: in expansion of macro 'DECLARE_INTC_DESC'
538 | static DECLARE_INTC_DESC(intc_desc_irl4567, "sh7785-irl4567", vectors_irl4567,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:106:33: note: in expansion of macro '_INTC_ARRAY'
106 | _INTC_ARRAY(mask_regs), _INTC_ARRAY(prio_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:538:8: note: in expansion of macro 'DECLARE_INTC_DESC'
538 | static DECLARE_INTC_DESC(intc_desc_irl4567, "sh7785-irl4567", vectors_irl4567,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:538:8: note: in expansion of macro 'DECLARE_INTC_DESC'
538 | static DECLARE_INTC_DESC(intc_desc_irl4567, "sh7785-irl4567", vectors_irl4567,
| ^~~~~~~~~~~~~~~~~
./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
| ^
./include/linux/sh_intc.h:107:34: note: in expansion of macro '_INTC_ARRAY'
107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
| ^~~~~~~~~~~
./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
| ^~~~~~~~~~~~
arch/sh/kernel/cpu/sh4a/setup-sh7785.c:538:8: note: in expansion of macro 'DECLARE_INTC_DESC'
538 | static DECLARE_INTC_DESC(intc_desc_irl4567, "sh7785-irl4567", vectors_irl4567,
| ^~~~~~~~~~~~~~~~~
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
) Hi Adrian,
On Wed, Jun 30, 2021 at 9:36 PM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 6/30/21 9:33 PM, Randy Dunlap wrote:
> > On 6/30/21 2:36 AM, John Paul Adrian Glaubitz wrote:
> >> On 6/28/21 12:05 AM, Randy Dunlap wrote:
> >>> kernel.h defines READ and WRITE, so rename the SH math-emu macros
> >>> to MREAD and MWRITE.
> >>>
> >>> Fixes these warnings:
> >>>
> >>> ../arch/sh/math-emu/math.c:54: warning: "WRITE" redefined
> >>> 54 | #define WRITE(d,a) ({if(put_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> >>> In file included from ../arch/sh/math-emu/math.c:10:
> >>> ../include/linux/kernel.h:37: note: this is the location of the previous definition
> >>> 37 | #define WRITE 1
> >>> ../arch/sh/math-emu/math.c:55: warning: "READ" redefined
> >>> 55 | #define READ(d,a) ({if(get_user(d, (typeof (d) __user *)a)) return -EFAULT;})
> >>> In file included from ../arch/sh/math-emu/math.c:10:
> >>> ../include/linux/kernel.h:36: note: this is the location of the previous definition
> >>> 36 | #define READ 0
> >>>
> >>> Fixes: 4b565680d163 ("sh: math-emu support")
> >>> Signed-off-by: Randy Dunlap <[email protected]>
> >>> Cc: Yoshinori Sato <[email protected]>
> >>> Cc: Rich Felker <[email protected]>
> >>> Cc: [email protected]
> >>> Cc: Takashi YOSHII <[email protected]>
> >>> Cc: John Paul Adrian Glaubitz <[email protected]>
> >>> Cc: Geert Uytterhoeven <[email protected]>
> >>> ---
> >>> v2: renumber patches, otherwise no change;
> >>>
> >>> arch/sh/math-emu/math.c | 44 +++++++++++++++++++-------------------
> >>> 1 file changed, 22 insertions(+), 22 deletions(-)
> >> This one no longer applies to Linus' tree:
> >>
> >> glaubitz@node54:/data/home/glaubitz/linux> git am ../sh-patches-2021/\[PATCH\ 3_3\ v2\]\ sh\:\ fix\ READ_WRITE\ redefinition\ warnings.eml
> >> Applying: sh: fix READ/WRITE redefinition warnings
> >> error: patch failed: arch/sh/math-emu/math.c:51
> >> error: arch/sh/math-emu/math.c: patch does not apply
> >> Patch failed at 0001 sh: fix READ/WRITE redefinition warnings
> >> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> >> When you have resolved this problem, run "git am --continue".
> >> If you prefer to skip this patch, run "git am --skip" instead.
> >> To restore the original branch and stop patching, run "git am --abort".
> >> glaubitz@node54:/data/home/glaubitz/linux>
> >
> > OK. Thanks for all of the testing.
>
> I'll report back with the other patch applied that Geert mentioned from linux-next before this one.
FTR, I booted all three successfully on qemu/rts7751r2d and on physical landisk.
> FWIW, there are some warnings when building the SH-7785LCR configuration:
>
> In file included from ./arch/sh/include/asm/hw_irq.h:6,
> from ./include/linux/irq.h:591,
> from ./include/asm-generic/hardirq.h:17,
> from ./arch/sh/include/asm/hardirq.h:9,
> from ./include/linux/hardirq.h:11,
> from ./include/linux/interrupt.h:11,
> from ./include/linux/serial_core.h:13,
> from ./include/linux/serial_sci.h:6,
> from arch/sh/kernel/cpu/sh4a/setup-sh7785.c:10:
> ./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
> 100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
> | ^
> ./include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
> 107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
> | ^~~~~~~~~~~
> ./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
> 124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
> | ^~~~~~~~~~~~
> arch/sh/kernel/cpu/sh4a/setup-sh7785.c:478:8: note: in expansion of macro 'DECLARE_INTC_DESC'
> 478 | static DECLARE_INTC_DESC(intc_desc, "sh7785", vectors, groups,
> | ^~~~~~~~~~~~~~~~~
A while ago, I had a look into fixing them, but it was non-trivial.
The issue is that the macros are sometimes used with NULL pointer arrays.
The __same_type() check in
#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
is supposed to catch that, but modern compilers seem to evaluate the
non-taken branch, too, leading to the warning.
Anyone with a suggestion? (CCing the multi-compiler guru)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Jul 1, 2021 at 10:41 AM Geert Uytterhoeven <[email protected]> wrote:
> On Wed, Jun 30, 2021 at 9:36 PM John Paul Adrian Glaubitz <[email protected]> wrote:
> > On 6/30/21 9:33 PM, Randy Dunlap wrote:
> > > On 6/30/21 2:36 AM, John Paul Adrian Glaubitz wrote:
>
> > FWIW, there are some warnings when building the SH-7785LCR configuration:
> >
> > In file included from ./arch/sh/include/asm/hw_irq.h:6,
> > from ./include/linux/irq.h:591,
> > from ./include/asm-generic/hardirq.h:17,
> > from ./arch/sh/include/asm/hardirq.h:9,
> > from ./include/linux/hardirq.h:11,
> > from ./include/linux/interrupt.h:11,
> > from ./include/linux/serial_core.h:13,
> > from ./include/linux/serial_sci.h:6,
> > from arch/sh/kernel/cpu/sh4a/setup-sh7785.c:10:
> > ./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
> > 100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
> > | ^
> > ./include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
> > 107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
> > | ^~~~~~~~~~~
> > ./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
> > 124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
> > | ^~~~~~~~~~~~
> > arch/sh/kernel/cpu/sh4a/setup-sh7785.c:478:8: note: in expansion of macro 'DECLARE_INTC_DESC'
> > 478 | static DECLARE_INTC_DESC(intc_desc, "sh7785", vectors, groups,
> > | ^~~~~~~~~~~~~~~~~
>
> A while ago, I had a look into fixing them, but it was non-trivial.
> The issue is that the macros are sometimes used with NULL pointer arrays.
> The __same_type() check in
>
> #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
>
> is supposed to catch that, but modern compilers seem to evaluate the
> non-taken branch, too, leading to the warning.
>
> Anyone with a suggestion? (CCing the multi-compiler guru)
I think I looked at this (or maybe a related sh driver) in the past
and also gave up.
The best idea I have would be to manually expand the DECLARE_INTC_DESC()
macros. It would be possible to add further variations of them for each
combination of NULL/non-NULL arguments, but IMHO they don't actually
add any readability over the expanded version in the first place.
Another option would be to change the definition from array/size to
zero-terminated
arrays and get rid of the sizeof hack.
Arnd
Hi Geert!
On 7/1/21 10:41 AM, Geert Uytterhoeven wrote:
>>> OK. Thanks for all of the testing.
>>
>> I'll report back with the other patch applied that Geert mentioned from linux-next before this one.
>
> FTR, I booted all three successfully on qemu/rts7751r2d and on physical landisk.
Good to know, thanks.
>> FWIW, there are some warnings when building the SH-7785LCR configuration:
>>
>> In file included from ./arch/sh/include/asm/hw_irq.h:6,
>> from ./include/linux/irq.h:591,
>> from ./include/asm-generic/hardirq.h:17,
>> from ./arch/sh/include/asm/hardirq.h:9,
>> from ./include/linux/hardirq.h:11,
>> from ./include/linux/interrupt.h:11,
>> from ./include/linux/serial_core.h:13,
>> from ./include/linux/serial_sci.h:6,
>> from arch/sh/kernel/cpu/sh4a/setup-sh7785.c:10:
>> ./include/linux/sh_intc.h:100:63: warning: division 'sizeof (void *) / sizeof (void)' does not compute the number of array elements [-Wsizeof-pointer-div]
>> 100 | #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
>> | ^
>> ./include/linux/sh_intc.h:107:9: note: in expansion of macro '_INTC_ARRAY'
>> 107 | _INTC_ARRAY(sense_regs), _INTC_ARRAY(ack_regs), \
>> | ^~~~~~~~~~~
>> ./include/linux/sh_intc.h:124:15: note: in expansion of macro 'INTC_HW_DESC'
>> 124 | .hw = INTC_HW_DESC(vectors, groups, mask_regs, \
>> | ^~~~~~~~~~~~
>> arch/sh/kernel/cpu/sh4a/setup-sh7785.c:478:8: note: in expansion of macro 'DECLARE_INTC_DESC'
>> 478 | static DECLARE_INTC_DESC(intc_desc, "sh7785", vectors, groups,
>> | ^~~~~~~~~~~~~~~~~
>
> A while ago, I had a look into fixing them, but it was non-trivial.
> The issue is that the macros are sometimes used with NULL pointer arrays.
> The __same_type() check in
>
> #define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
>
> is supposed to catch that, but modern compilers seem to evaluate the
> non-taken branch, too, leading to the warning.
>
> Anyone with a suggestion? (CCing the multi-compiler guru)
Ah, thanks for the explanation.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/27/21 3:05 PM, Randy Dunlap wrote:
> Fix a few build warnings and one kconfig warning on SUPERH.
>
> v2: add a previously-sent Kconfig patch
> add a few more Cc's
>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Cc: John Paul Adrian Glaubitz <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
>
> [PATCH 1/3 v2] sh: fix kconfig unmet dependency warning for FRAME_POINTER
> [PATCH 2/3 v2] sh: define __BIG_ENDIAN for math-emu
> [PATCH 3/3 v2] sh: fix READ/WRITE redefinition warnings
>
> arch/sh/Kconfig.debug | 1
> arch/sh/include/asm/sfp-machine.h | 8 +++++
> arch/sh/math-emu/math.c | 44 ++++++++++++++--------------
> 3 files changed, 31 insertions(+), 22 deletions(-)
>
Hi Rich and Yoshinori,
What is the status of arch/sh/ in general and
of these patches in particular?
thanks.
--
~Randy
Hi Randy!
On 9/8/21 22:19, Randy Dunlap wrote:
> What is the status of arch/sh/ in general and
> of these patches in particular?
I've also been trying to reach out to Yoshinori and Rich. I know that Yoshinori is
currently busy with other work but he can be reached over Twitter [1]. I don't
know about Rich though.
There are quite a number of patches on the mailing list that need reviewing and
I fear if that doesn't happen in the foreseeable future, the SH port is being
kicked out which would be a pity given that we're still maintaining the port in
Debian and given that there is new hardware available with the J-Core board [2].
Adrian
> [1] https://twitter.com/ysat0/
> [2] https://www.cnx-software.com/2017/03/13/turtle-board-is-a-raspberry-pi-2-like-fpga-board-for-j-core-j2-open-source-superh-sh2-soc/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
HI Adrian,
On Thu, 9 Sept 2021 at 17:25, John Paul Adrian Glaubitz
<[email protected]> wrote:
> There are quite a number of patches on the mailing list that need reviewing and
> I fear if that doesn't happen in the foreseeable future, the SH port is being
> kicked out which would be a pity given that we're still maintaining the port in
> Debian and given that there is new hardware available with the J-Core board [2].
This really is a poor situation. The fact that there are patches means
that it's not totally dead but no one ever looking at them really puts
people off bothering in the future.
I might have a go at getting OF to work on the SH4 hardware I have but
knowing that the patches will probably never get looked at is very
demotivating.
Can we get a new maintainer from somewhere?
Cheers,
Daniel
On 9/9/21 3:25 AM, John Paul Adrian Glaubitz wrote:
> Hi Randy!
>
> On 9/8/21 22:19, Randy Dunlap wrote:
>> What is the status of arch/sh/ in general and
>> of these patches in particular?
>
> I've also been trying to reach out to Yoshinori and Rich. I know that Yoshinori is
> currently busy with other work but he can be reached over Twitter [1]. I don't
> know about Rich though.
https://twitter.com/richfelker
(That said I believe he's on a road trip with his family this week?)
> There are quite a number of patches on the mailing list that need reviewing and
> I fear if that doesn't happen in the foreseeable future, the SH port is being
> kicked out which would be a pity given that we're still maintaining the port in
> Debian and given that there is new hardware available with the J-Core board [2].
Rich tends to miss things that go by on the list, or silently assume things will
go in through somebody else's tree. That said he responds to email and if all
else fails I have his cell phone number, so poke _me_ about it. :)
What I _don't_ have is the technical expertise to say more than "yup it compiled
and ran on qemu and/or my turtle board". (I have two other pieces of sh4
hardware and an original sh2 board, but they're in austin and I'm in chicago at
the moment, and none of them has a particularly friendly bootloader for feeding
new kernel images into.)
If you just want "it worked", I can sign off on that. If you want "is it a good
idea", that's a higher bar.
Rob
On Thu, Sep 09, 2021 at 06:08:58PM +0900, Daniel Palmer wrote:
> HI Adrian,
>
> On Thu, 9 Sept 2021 at 17:25, John Paul Adrian Glaubitz
> <[email protected]> wrote:
> > There are quite a number of patches on the mailing list that need reviewing and
> > I fear if that doesn't happen in the foreseeable future, the SH port is being
> > kicked out which would be a pity given that we're still maintaining the port in
> > Debian and given that there is new hardware available with the J-Core board [2].
>
> This really is a poor situation. The fact that there are patches means
> that it's not totally dead but no one ever looking at them really puts
> people off bothering in the future.
> I might have a go at getting OF to work on the SH4 hardware I have but
> knowing that the patches will probably never get looked at is very
> demotivating.
>
> Can we get a new maintainer from somewhere?
Hi. I see there's a situation that needs my attention here. I will
plan to review and merge anything important/blocking that doesn't have
problems this week.
In the bigger picture, the past few weeks and even months I've been in
a sort of "avoid burnout safety mode". :-) Probably partly on account
of this pandemic still being a thing because people insist on being
stupid. I'm not gone and won't be, but some things that haven't seemed
as urgent, including kernel stuff and especially piles of email of
mixed importance levels, have gotten pushed back to reduce stress.
Please don't hesitate to wave a "hey this is important, come take a
quick look!" flag at me if needed.
At the same time, I am open to the possibility of a new maintainer or
co-maintainer if that ends up being what makes sense. Are there any
candidates?
Rich
Hi Rich!
On 9/12/21 03:57, Rich Felker wrote:
> Hi. I see there's a situation that needs my attention here. I will
> plan to review and merge anything important/blocking that doesn't have
> problems this week.
I'm glad to here that you're still active. I will try to help assembling
the list of patches. I won't be able to test them though as I'm not at
home so I'm unable to reset the machine in case it crashes due to a bad
kernel patch. So, basically, I just have one shot free.
> In the bigger picture, the past few weeks and even months I've been in
> a sort of "avoid burnout safety mode". :-) Probably partly on account
> of this pandemic still being a thing because people insist on being
> stupid. I'm not gone and won't be, but some things that haven't seemed
> as urgent, including kernel stuff and especially piles of email of
> mixed importance levels, have gotten pushed back to reduce stress.
> Please don't hesitate to wave a "hey this is important, come take a
> quick look!" flag at me if needed.
We definitely need to get all those patches merged that fix warnings as Linus
recently moved to building with -Werror by default.
> At the same time, I am open to the possibility of a new maintainer or
> co-maintainer if that ends up being what makes sense. Are there any
> candidates?
I would generally be interested to help although I'm not as knowledgeable
when it comes to low-level kernel development.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 9/12/21 5:36 AM, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> On 9/12/21 03:57, Rich Felker wrote:
>> Hi. I see there's a situation that needs my attention here. I will
>> plan to review and merge anything important/blocking that doesn't have
>> problems this week.
>
> I'm glad to here that you're still active. I will try to help assembling
> the list of patches. I won't be able to test them though as I'm not at
> home so I'm unable to reset the machine in case it crashes due to a bad
> kernel patch. So, basically, I just have one shot free.
I smoketest on qemu-system-sh4 first just because it's so convenient, then test
on my j-core (sh2+) turtle board because it's the next most convenient thing
(it's USB powered and one lives in my backpack).
>> At the same time, I am open to the possibility of a new maintainer or
>> co-maintainer if that ends up being what makes sense. Are there any
>> candidates?
>
> I would generally be interested to help although I'm not as knowledgeable
> when it comes to low-level kernel development.
I'm in a similar position: I can put more cycles into this (and I've collected
patch stacks for Rich before), but I don't have the domain expertise to make
judgement calls about device tree representation, interrupt routing, nontrivial
lock ordering, knowing when you need a memory barrier and why...
(Also, I've been running up to 3 days behind on my email recently, and catching
up on weekends...)
Rob
Hi Rich,
On Sun, 12 Sept 2021 at 10:57, Rich Felker <[email protected]> wrote:
>
> On Thu, Sep 09, 2021 at 06:08:58PM +0900, Daniel Palmer wrote:
> Hi. I see there's a situation that needs my attention here. I will
> plan to review and merge anything important/blocking that doesn't have
> problems this week.
Great. If you want to have it tested on real hardware please let me know.
I have an ecovec24 (SH4A) board connected to CI so I can easily build
and boot test.
> At the same time, I am open to the possibility of a new maintainer or
> co-maintainer if that ends up being what makes sense. Are there any
> candidates?
I think the problem is that while there are hobbyists out there the
number of people that are still familiar with how the SuperH stuff
works is pretty low.
I don't have the debug dongles etc anymore so if some treewide change
breaks everything then I don't know how I'd debug it.
Maybe we could add a few people that still have working hardware as
reviewers so they see patches and build test them for you?
Cheers,
Daniel
On Sun, Sep 12, 2021 at 12:36:38PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
>
> On 9/12/21 03:57, Rich Felker wrote:
> > Hi. I see there's a situation that needs my attention here. I will
> > plan to review and merge anything important/blocking that doesn't have
> > problems this week.
>
> I'm glad to here that you're still active. I will try to help assembling
> the list of patches. I won't be able to test them though as I'm not at
> home so I'm unable to reset the machine in case it crashes due to a bad
> kernel patch. So, basically, I just have one shot free.
I didn't get through that yet, but I have rebased the patches that
were pending in for-next onto v5.15-rc1 (no conflicts) and
smoke-tested that a sh4 build runs in my qemu environment. linux-next
pulled them 27 hours ago and hasn't complained yet either.
I started going through the list/patch backlog, but didn't make it
nearly as far as I'd like yet. If you have even a vague list of what's
important (warnings breaking the build, unapplied changes blocking
removal of cruft from other parts of the kernel and making people
unhappy with us, etc.) that would be really helpful.
I'll follow up again soon.
Rich
Hi Rich!
On 9/22/21 04:45, Rich Felker wrote:
> I didn't get through that yet, but I have rebased the patches that
> were pending in for-next onto v5.15-rc1 (no conflicts) and
> smoke-tested that a sh4 build runs in my qemu environment. linux-next
> pulled them 27 hours ago and hasn't complained yet either.
Sounds promising, thanks!
> I started going through the list/patch backlog, but didn't make it
> nearly as far as I'd like yet. If you have even a vague list of what's
> important (warnings breaking the build, unapplied changes blocking
> removal of cruft from other parts of the kernel and making people
> unhappy with us, etc.) that would be really helpful.
I will start testing kernel updates again from next week as I'm currently
busy with other open source work I want to get off my table first.
> I'll follow up again soon.
Thanks, looking forward for more updates.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Rich!
On 9/22/21 04:45, Rich Felker wrote:
> I didn't get through that yet, but I have rebased the patches that
> were pending in for-next onto v5.15-rc1 (no conflicts) and
> smoke-tested that a sh4 build runs in my qemu environment. linux-next
> pulled them 27 hours ago and hasn't complained yet either.
Do we need another PR against Linus' tree from your side or are they pulled
in automatically?
> I started going through the list/patch backlog, but didn't make it
> nearly as far as I'd like yet. If you have even a vague list of what's
> important (warnings breaking the build, unapplied changes blocking
> removal of cruft from other parts of the kernel and making people
> unhappy with us, etc.) that would be really helpful.
>
> I'll follow up again soon.
Any news on this?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913