From: Joe Perches <joe@perches.com> Date: 2020-05-04 23:29:05
IS_BUILTIN can be use to replace various initializations
like #if CONFIG_<FOO> int val = 1; #else int val = 0; #endif
so do so.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/video/fbdev/aty/aty128fb.c | 6 +-----
drivers/video/fbdev/aty/atyfb_base.c | 7 +------
drivers/video/fbdev/aty/radeon_base.c | 6 +-----
drivers/video/fbdev/nvidia/nvidia.c | 6 +-----
drivers/video/fbdev/omap/omapfb_main.c | 6 +-----
drivers/video/fbdev/riva/fbdev.c | 6 +-----
drivers/video/fbdev/s3c2410fb.c | 6 +-----
7 files changed, 7 insertions(+), 36 deletions(-)
@@ -269,11 +269,7 @@ static bool force_measure_pll = 0;staticboolnomtrr=0;staticboolforce_sleep;staticboolignore_devlist;-#ifdef CONFIG_PMAC_BACKLIGHT-staticintbacklight=1;-#else-staticintbacklight=0;-#endif+staticintbacklight=IS_BUILTIN(CONFIG_PMAC_BACKLIGHT);/* Note about this function: we have some rare cases where we must not schedule,*thistypicallyhappenwithourspecial"wake up early"hookwhichallowsusto
IS_BUILTIN can be use to replace various initializations
like #if CONFIG_<FOO> int val = 1; #else int val = 0; #endif
so do so.
Signed-off-by: Joe Perches <joe@perches.com>
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
@@ -269,11 +269,7 @@ static bool force_measure_pll = 0;staticboolnomtrr=0;staticboolforce_sleep;staticboolignore_devlist;-#ifdef CONFIG_PMAC_BACKLIGHT-staticintbacklight=1;-#else-staticintbacklight=0;-#endif+staticintbacklight=IS_BUILTIN(CONFIG_PMAC_BACKLIGHT);/* Note about this function: we have some rare cases where we must not schedule,*thistypicallyhappenwithourspecial"wake up early"hookwhichallowsusto
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
@@ -576,14 +576,8 @@ static u_short maxfmode, chipset;#define modx(x, v) ((v) & ((x) - 1))/* if x1 is not a constant, this macro won't make real sense :-) */-#ifdef __mc68000__#define DIVUL(x1, x2) ({int res; asm("divul %1,%2,%3": "=d" (res): \"d"(x2),"d"((long)((x1)/0x100000000ULL)),"0"((long)(x1)));res;})-#else-/* We know a bit about the numbers, so we can do it this way */-#define DIVUL(x1, x2) ((((long)((unsigned long long)x1 >> 8) / x2) << 8) + \-((((long)((unsignedlonglong)x1>>8)%x2)<<8)/x2))-#endif#define highw(x) ((u_long)(x)>>16 & 0xffff)#define loww(x) ((u_long)(x) & 0xffff)
@@ -1837,11 +1831,7 @@ static int ami_get_var_cursorinfo(structconststructamifb_par*par){registeru_short*lspr,*sspr;-#ifdef __mc68000__registeru_longdatawordsasm("d2");-#else-registeru_longdatawords;-#endifregistershortdelta;registeru_charcolor;shortheight,width,bits,words;
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
---
drivers/video/fbdev/amifb.c | 2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/video/fbdev/amifb.c
=================================--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -1866,6 +1866,7 @@ static int ami_get_var_cursorinfo(struct"clrb %0 ; swap %1 ; lslw #1,%1 ; roxlb #1,%0 ; ""swap %1 ; lslw #1,%1 ; roxlb #1,%0":"=d"(color),"=d"(datawords):"1"(datawords));+/* FIXME: check the return value + test the change */put_user(color,data++);}if(bits>0){
@@ -1923,6 +1924,7 @@ static int ami_set_var_cursorinfo(structbits=16;words=delta;datawords=0;for(width=(short)var->width-1;width>=0;width--){unsignedlongtdata=0;+/* FIXME: check the return value + test the change */get_user(tdata,data);data++;asmvolatile(
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Date: 2020-06-02 10:41:46
Hi Geert!
On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote:
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
What do you mean with the sentence "when arch/ppc/ was still king"?
Does that mean - in the case we would re-add APUS support in the future, that
these particular changes would not be necessary?
I assume there could be new affordable PowerPC upgrade cards for the Amiga
in the future as the PowerPC cards are still sought after by the Amiga
community, so there is still demand for those on the market.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
On Tue, Jun 2, 2020 at 12:41 PM John Paul Adrian Glaubitz
[off-list ref] wrote:
On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote:
quoted
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
What do you mean with the sentence "when arch/ppc/ was still king"?
Ah, Bartl copied that from my email ;-)
There used to be APUS support under arch/ppc/.
Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\
architecture port under arch/powerpc/, and the old ones were dropped.
APUS was never converted, and thus dropped.
Does that mean - in the case we would re-add APUS support in the future, that
these particular changes would not be necessary?
They would still be necessary, as PowerPC doesn't grok m68k instructions.
Alternatively, we could just drop the m68k inline asm, and retain the C
version instead? I have no idea how big of a difference that would make
on m68k, using a more modern compiler than when the code was written
originally.
Note that all of this is used only for cursor handling, which I doubt is
actually used by any user space application. The only exception is the
DIVUL() macro, which is used once during initialization, thus also not
performance critical.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Date: 2020-06-02 11:07:40
Hi!
On 6/2/20 1:04 PM, Geert Uytterhoeven wrote:
quoted
What do you mean with the sentence "when arch/ppc/ was still king"?
Ah, Bartl copied that from my email ;-)
There used to be APUS support under arch/ppc/.
Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\
architecture port under arch/powerpc/, and the old ones were dropped.
APUS was never converted, and thus dropped.
Ah, yes. Similar to the merge with x86.
quoted
Does that mean - in the case we would re-add APUS support in the future, that
these particular changes would not be necessary?
They would still be necessary, as PowerPC doesn't grok m68k instructions.
Alternatively, we could just drop the m68k inline asm, and retain the C
version instead? I have no idea how big of a difference that would make
on m68k, using a more modern compiler than when the code was written
originally.
Hmm, no idea. I would keep the assembly for the time being. This was just
a question out of curiosity. We could still consider such a change if
someone should consider working on APUS support again.
Note that all of this is used only for cursor handling, which I doubt is
actually used by any user space application. The only exception is the
DIVUL() macro, which is used once during initialization, thus also not
performance critical.
I see, thanks.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/2/20 1:07 PM, John Paul Adrian Glaubitz wrote:
Hi!
On 6/2/20 1:04 PM, Geert Uytterhoeven wrote:
quoted
quoted
What do you mean with the sentence "when arch/ppc/ was still king"?
Ah, Bartl copied that from my email ;-)
There used to be APUS support under arch/ppc/.
Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\
architecture port under arch/powerpc/, and the old ones were dropped.
APUS was never converted, and thus dropped.
Ah, yes. Similar to the merge with x86.
quoted
quoted
Does that mean - in the case we would re-add APUS support in the future, that
these particular changes would not be necessary?
They would still be necessary, as PowerPC doesn't grok m68k instructions.
Alternatively, we could just drop the m68k inline asm, and retain the C
version instead? I have no idea how big of a difference that would make
on m68k, using a more modern compiler than when the code was written
originally.
Hmm, no idea. I would keep the assembly for the time being. This was just
a question out of curiosity. We could still consider such a change if
someone should consider working on APUS support again.
quoted
Note that all of this is used only for cursor handling, which I doubt is
actually used by any user space application. The only exception is the
DIVUL() macro, which is used once during initialization, thus also not
performance critical.
I see, thanks.
Since the code in question is not performance critical it indeed seems to
be good idea to use C version. However it still would need be tested on
the hardware (or emulator at least) so for the time being I think that we
should just add another FIXME comment instead of doing real code changes..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
Add FIXME about using the C code variants (APUS ones) in the future.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
---
v2:
- added FIXME comment instead of removing the C code variants
drivers/video/fbdev/amifb.c | 6 ++++++
1 file changed, 6 insertions(+)
Index: b/drivers/video/fbdev/amifb.c
=================================--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -575,6 +575,12 @@ static u_short maxfmode, chipset;#define downx(x, v) ((v) & -(x))#define modx(x, v) ((v) & ((x) - 1))+/*+*FIXME:UseCvariantsofthecodemarkedwith#ifdef__mc68000__+*inthedriver.Itshouldn'tnegativelyaffecttheperformanceand+*isrequiredforAPUSsupport(onceitisre-addedtothekernel).+*Needstobetestedonthehardwarethough..+*//* if x1 is not a constant, this macro won't make real sense :-) */#ifdef __mc68000__#define DIVUL(x1, x2) ({int res; asm("divul %1,%2,%3": "=d" (res): \
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
---
v2:
- rebased on top of updated patch #1/2
drivers/video/fbdev/amifb.c | 2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/video/fbdev/amifb.c
=================================--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -1892,6 +1892,7 @@ static int ami_get_var_cursorinfo(struct|((datawords>>15)&1));datawords<<=1;#endif+/* FIXME: check the return value + test the change */put_user(color,data++);}if(bits>0){
@@ -1962,6 +1963,7 @@ static int ami_set_var_cursorinfo(structbits=16;words=delta;datawords=0;for(width=(short)var->width-1;width>=0;width--){unsignedlongtdata=0;+/* FIXME: check the return value + test the change */get_user(tdata,data);data++;#ifdef __mc68000__
On Tue, Jun 2, 2020 at 1:50 PM Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
Add FIXME about using the C code variants (APUS ones) in the future.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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 Tue, Jun 2, 2020 at 1:52 PM Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
From: Al Viro <viro@zeniv.linux.org.uk> Date: 2020-06-02 16:12:32
On Tue, Jun 02, 2020 at 02:03:12PM +0200, Geert Uytterhoeven wrote:
On Tue, Jun 2, 2020 at 1:50 PM Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
quoted
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
Add FIXME about using the C code variants (APUS ones) in the future.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
FWIW, has anyone managed to boot m68k linux kernel on e.g. FS-UAE?
I have done that on aranym (which is how I'd been doing all
testing for e.g. signal-related m68k patches) and I've seen
references to some out-of-tree qemu variant doing quadra, but
nothing for amiga emulators...
From: Finn Thain <hidden> Date: 2020-06-03 00:20:26
On Tue, 2 Jun 2020, Al Viro wrote:
I have done that on aranym (which is how I'd been doing all testing for
e.g. signal-related m68k patches) and I've seen references to some
out-of-tree qemu variant doing quadra, but nothing for amiga
emulators...
Laurent Vivier's Quadra 800 emulation is no longer out of tree. It
appeared in QEMU v4.2.0 and ethernet support was stabilized in QEMU
v5.0.0.
From: Emil Velikov <hidden> Date: 2020-06-15 20:38:55
Hi Bartlomiej,
On Tue, 2 Jun 2020 at 11:37, Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
A quick look through my checkout (drm-misc/next aka 5.8 ish), shows
multiple other places which check for the define.
And a single place where it's being set - the Makefile below.
Should those be addressed as well? Or perhaps they are and I've got an old tree.
HTH
Emil
$ git grep -c __mc68000__
arch/m68k/Makefile:1
drivers/block/floppy.c:2
drivers/ide/ide-probe.c:2
drivers/input/misc/hp_sdc_rtc.c:1
drivers/input/serio/hp_sdc.c:3
drivers/input/serio/hp_sdc_mlc.c:1
drivers/net/ethernet/i825xx/82596.c:8
drivers/tty/vt/keyboard.c:1
drivers/video/fbdev/amifb.c:11
include/linux/a.out.h:1
include/linux/hp_sdc.h:1
include/uapi/linux/a.out.h:1
lib/fonts/fonts.c:2
lib/mpi/longlong.h:1
Hi Emil,
On Mon, Jun 15, 2020 at 10:38 PM Emil Velikov [off-list ref] wrote:
On Tue, 2 Jun 2020 at 11:37, Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
quoted
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
A quick look through my checkout (drm-misc/next aka 5.8 ish), shows
multiple other places which check for the define.
And a single place where it's being set - the Makefile below.
Should those be addressed as well? Or perhaps they are and I've got an old tree.
Only the above apply to APUS support.
All other below are probably legitimate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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 Tue, Jun 2, 2020 at 1:50 PM Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
quoted
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
quoted
These #ifdefs are relics from APUS (Amiga Power-Up System), which
added a PPC board. APUS support was killed off a long time ago,
when arch/ppc/ was still king, but these #ifdefs were missed, because
they didn't test for CONFIG_APUS.
Add FIXME about using the C code variants (APUS ones) in the future.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>
On Tue, Jun 2, 2020 at 1:52 PM Bartlomiej Zolnierkiewicz
[off-list ref] wrote:
quoted
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <redacted>