Re: const __init
On Sunday 20 May 2001 21:51, Geert Uytterhoeven wrote: > Since a while include/linux/init.h contains the line > > * Also note, that this data cannot be "const". > > Why is this? Because const data will be put in a different section? Yes, and gcc3 errors on these constructs, cause it cannot decide if the data should be put into a .data or .rodata section. Dunno if it's worth to create a __initconstdata/__initrodata though, but it would be easy implement I guess. > drivers/video/aty128fb.c Fixed in bk 2_4. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: const __init
On Sunday 20 May 2001 21:51, Geert Uytterhoeven wrote: Since a while include/linux/init.h contains the line * Also note, that this data cannot be const. Why is this? Because const data will be put in a different section? Yes, and gcc3 errors on these constructs, cause it cannot decide if the data should be put into a .data or .rodata section. Dunno if it's worth to create a __initconstdata/__initrodata though, but it would be easy implement I guess. drivers/video/aty128fb.c Fixed in bk 2_4. Franz. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB Config fix for 2.2.19-pre7
At 08:26 2001-01-12, Greg KH wrote: >On Thu, Jan 11, 2001 at 06:01:19PM +0100, Franz Sirl wrote: > > Why do the input handlers depend on CONFIG_USB_HID? On PPC we already have > > trouble with them depending on CONFIG_USB, so everybody has to select > > CONFIG_USB even if he just has ADB hardware. > >Don't these input drivers _require_ the USB HID driver core to work >properly? No. >Or am I mistaken, and this is the 2.4.0 input core code, but >not in a separate directory, like 2.4.0 has it? Yes, it's the input core code, but without a separate directory or main_menu entry :-(. That means that currently on PPC people have to select CONFIG_USB even if they just want to have the input core code for CONFIG_INPUT_ADBHID. Since Alan rejected the creation of drivers/input in 2.2 for unknown (?) reasons, I suggest to add a 2nd main_menu in usb/Config.in for CONFIG_INPUT items. Then adjust drivers/Makefile in a way that drivers/usb is entered if CONFIG_USB is unset but CONFIG_INPUT is set. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB Config fix for 2.2.19-pre7
At 08:26 2001-01-12, Greg KH wrote: On Thu, Jan 11, 2001 at 06:01:19PM +0100, Franz Sirl wrote: Why do the input handlers depend on CONFIG_USB_HID? On PPC we already have trouble with them depending on CONFIG_USB, so everybody has to select CONFIG_USB even if he just has ADB hardware. Don't these input drivers _require_ the USB HID driver core to work properly? No. Or am I mistaken, and this is the 2.4.0 input core code, but not in a separate directory, like 2.4.0 has it? Yes, it's the input core code, but without a separate directory or main_menu entry :-(. That means that currently on PPC people have to select CONFIG_USB even if they just want to have the input core code for CONFIG_INPUT_ADBHID. Since Alan rejected the creation of drivers/input in 2.2 for unknown (?) reasons, I suggest to add a 2nd main_menu in usb/Config.in for CONFIG_INPUT items. Then adjust drivers/Makefile in a way that drivers/usb is entered if CONFIG_USB is unset but CONFIG_INPUT is set. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB Config fix for 2.2.19-pre7
At 01:44 2001-01-11, Greg KH wrote: >Hi, > >Here's a fix for the USB Config for 2.2.19-pre7. I messed up and took >out the HID devices in the patch I sent you for 2.2.19-pre6. Why do the input handlers depend on CONFIG_USB_HID? On PPC we already have trouble with them depending on CONFIG_USB, so everybody has to select CONFIG_USB even if he just has ADB hardware. Alan, would you accept a patch putting 2 main_menu's for CONFIG_USB and CONFIG_INPUT into usb/Config.in? This avoids the move of the input drivers into drivers/input as in 2.4 (which you seemingly don't want in 2.2) and only requires a minor adjustment in drivers/Makefile. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH] USB Config fix for 2.2.19-pre7
At 01:44 2001-01-11, Greg KH wrote: Hi, Here's a fix for the USB Config for 2.2.19-pre7. I messed up and took out the HID devices in the patch I sent you for 2.2.19-pre6. Why do the input handlers depend on CONFIG_USB_HID? On PPC we already have trouble with them depending on CONFIG_USB, so everybody has to select CONFIG_USB even if he just has ADB hardware. Alan, would you accept a patch putting 2 main_menu's for CONFIG_USB and CONFIG_INPUT into usb/Config.in? This avoids the move of the input drivers into drivers/input as in 2.4 (which you seemingly don't want in 2.2) and only requires a minor adjustment in drivers/Makefile. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
At 18:43 15.12.00, Andrea Arcangeli wrote: >On Fri, Dec 15, 2000 at 12:07:55PM -0500, Richard B. Johnson wrote: > > Current code makes perfect sense if you put a 'break;' after the last > >Current code makes perfect sense also without the break. I guess that's a >strict check to try to catch bugs, but calling it "deprecated" is wrong, it >should only say "warning: make sure that's not a bug" (when -Wall is enabled). It's required by ISO C, and since that's the standard now, gcc spits out a warning. Just adding a ; is enough and already done for most stuff in 2.4.0-test12. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 signal.h
At 18:43 15.12.00, Andrea Arcangeli wrote: On Fri, Dec 15, 2000 at 12:07:55PM -0500, Richard B. Johnson wrote: Current code makes perfect sense if you put a 'break;' after the last Current code makes perfect sense also without the break. I guess that's a strict check to try to catch bugs, but calling it "deprecated" is wrong, it should only say "warning: make sure that's not a bug" (when -Wall is enabled). It's required by ISO C, and since that's the standard now, gcc spits out a warning. Just adding a ; is enough and already done for most stuff in 2.4.0-test12. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Missing PPC merge bits
Hi Linus,
the appended patch contains the missing PPC bits for 2.4.0, patch OK'ed by
Paul Mackerras.
Franz.
* drivers/char/keyboard.c: Use key_maps[0] instead of plain_map to enable
proper keymap switching.
* drivers/input/keybdev.c: Bring PPC keycode handling up-to-date.
--- /cvsroot/linux_2_3/drivers/char/keyboard.c Mon Dec 4 14:59:20 2000
+++ linuxppc_2_3/drivers/char/keyboard.cSat Nov 25 17:50:09 2000
@@ -322,7 +322,7 @@ void handle_scancode(unsigned char scanc
compute_shiftstate();
kbd->slockstate = 0; /* play it safe */
#else
- keysym = U(plain_map[keycode]);
+ keysym = U(key_maps[0][keycode]);
type = KTYP(keysym);
if (type == KT_SHIFT)
(*key_handler[type])(keysym & 0xff, up_flag);
@@ -750,7 +750,7 @@ void compute_shiftstate(void)
k = i*BITS_PER_LONG;
for(j=0; j
#include
-#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(__alpha__) ||
defined(__mips__)
+#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(__alpha__) ||
+defined(__mips__) || defined(CONFIG_PPC)
static int x86_sysrq_alt = 0;
@@ -57,8 +57,46 @@ static unsigned short x86_keycodes[256]
308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+extern int mac_hid_mouse_emulate_buttons(int, int, int);
+#endif /* CONFIG_MAC_EMUMOUSEBTN */
+#ifdef CONFIG_MAC_ADBKEYCODES
+extern int mac_hid_keyboard_sends_linux_keycodes(void);
+#else
+#define mac_hid_keyboard_sends_linux_keycodes()0
+#endif /* CONFIG_MAC_ADBKEYCODES */
+#if defined(CONFIG_MAC_ADBKEYCODES) || defined(CONFIG_ADB_KEYBOARD)
+static unsigned char mac_keycodes[256] = {
+ 0, 53, 18, 19, 20, 21, 23, 22, 26, 28, 25, 29, 27, 24, 51, 48,
+12, 13, 14, 15, 17, 16, 32, 34, 31, 35, 33, 30, 36, 54,128, 1,
+ 2, 3, 5, 4, 38, 40, 37, 41, 39, 50, 56, 42, 6, 7, 8, 9,
+11, 45, 46, 43, 47, 44,123, 67, 58, 49, 57,122,120, 99,118, 96,
+97, 98,100,101,109, 71,107, 89, 91, 92, 78, 86, 87, 88, 69, 83,
+84, 85, 82, 65, 42, 0, 10,103,111, 0, 0, 0, 0, 0, 0, 0,
+76,125, 75,105,124,110,115, 62,116, 59, 60,119, 61,121,114,117,
+ 0, 0, 0, 0,127, 81, 0,113, 0, 0, 0, 0, 95, 55, 55, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 94, 0, 93, 0, 0, 0, 0, 0, 0,104,102 };
+#endif /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
+
static int emulate_raw(unsigned int keycode, int down)
{
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ if (mac_hid_mouse_emulate_buttons(1, keycode, down))
+ return 0;
+#endif /* CONFIG_MAC_EMUMOUSEBTN */
+#if defined(CONFIG_MAC_ADBKEYCODES) || defined(CONFIG_ADB_KEYBOARD)
+ if (!mac_hid_keyboard_sends_linux_keycodes()) {
+ if (keycode > 255 || !mac_keycodes[keycode])
+ return -1;
+
+ handle_scancode((mac_keycodes[keycode] & 0x7f), down);
+ return 0;
+ }
+#endif /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
+
if (keycode > 255 || !x86_keycodes[keycode])
return -1;
@@ -89,30 +127,7 @@ static int emulate_raw(unsigned int keyc
return 0;
}
-
-#elif defined(CONFIG_ADB_KEYBOARD)
-
-static unsigned char mac_keycodes[128] =
- { 0, 53, 18, 19, 20, 21, 23, 22, 26, 28, 25, 29, 27, 24, 51, 48,
-12, 13, 14, 15, 17, 16, 32, 34, 31, 35, 33, 30, 36, 54,128, 1,
- 2, 3, 5, 4, 38, 40, 37, 41, 39, 50, 56, 42, 6, 7, 8, 9,
-11, 45, 46, 43, 47, 44,123, 67, 58, 49, 57,122,120, 99,118, 96,
-97, 98,100,101,109, 71,107, 89, 91, 92, 78, 86, 87, 88, 69, 83,
-84, 85, 82, 65, 42, 0, 10,103,111, 0, 0, 0, 0, 0, 0, 0,
-76,125, 75,105,124, 0,115, 62,116, 59, 60,119, 61,121,114,117,
- 0, 0, 0, 0,127, 81, 0,113, 0, 0, 0, 0, 0, 55, 55 };
-
-static int emulate_raw(unsigned int keycode, int down)
-{
- if (keycode > 127 || !mac_keycodes[keycode])
- return -1;
-
- handle_scancode(mac_keycodes[keycode] & 0x7f, down);
-
- return 0;
-}
-
-#endif
+#endif /* CONFIG_X86 || CONFIG_IA64 || __alpha__ || __mips__ || CONFIG_PPC */
static struct input_handler keybdev_handler;
[PATCH] Missing PPC merge bits
Hi Linus,
the appended patch contains the missing PPC bits for 2.4.0, patch OK'ed by
Paul Mackerras.
Franz.
* drivers/char/keyboard.c: Use key_maps[0] instead of plain_map to enable
proper keymap switching.
* drivers/input/keybdev.c: Bring PPC keycode handling up-to-date.
--- /cvsroot/linux_2_3/drivers/char/keyboard.c Mon Dec 4 14:59:20 2000
+++ linuxppc_2_3/drivers/char/keyboard.cSat Nov 25 17:50:09 2000
@@ -322,7 +322,7 @@ void handle_scancode(unsigned char scanc
compute_shiftstate();
kbd-slockstate = 0; /* play it safe */
#else
- keysym = U(plain_map[keycode]);
+ keysym = U(key_maps[0][keycode]);
type = KTYP(keysym);
if (type == KT_SHIFT)
(*key_handler[type])(keysym 0xff, up_flag);
@@ -750,7 +750,7 @@ void compute_shiftstate(void)
k = i*BITS_PER_LONG;
for(j=0; jBITS_PER_LONG; j++,k++)
if(test_bit(k, key_down)) {
- sym = U(plain_map[k]);
+ sym = U(key_maps[0][k]);
if(KTYP(sym) == KT_SHIFT || KTYP(sym) == KT_SLOCK) {
val = KVAL(sym);
if (val == KVAL(K_CAPSSHIFT))
--- /cvsroot/linux_2_3/drivers/input/keybdev.c Mon Dec 4 15:00:12 2000
+++ linuxppc_2_3/drivers/input/keybdev.cThu Dec 7 19:39:41 2000
@@ -36,7 +36,7 @@
#include linux/module.h
#include linux/kbd_kern.h
-#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(__alpha__) ||
defined(__mips__)
+#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(__alpha__) ||
+defined(__mips__) || defined(CONFIG_PPC)
static int x86_sysrq_alt = 0;
@@ -57,8 +57,46 @@ static unsigned short x86_keycodes[256]
308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+extern int mac_hid_mouse_emulate_buttons(int, int, int);
+#endif /* CONFIG_MAC_EMUMOUSEBTN */
+#ifdef CONFIG_MAC_ADBKEYCODES
+extern int mac_hid_keyboard_sends_linux_keycodes(void);
+#else
+#define mac_hid_keyboard_sends_linux_keycodes()0
+#endif /* CONFIG_MAC_ADBKEYCODES */
+#if defined(CONFIG_MAC_ADBKEYCODES) || defined(CONFIG_ADB_KEYBOARD)
+static unsigned char mac_keycodes[256] = {
+ 0, 53, 18, 19, 20, 21, 23, 22, 26, 28, 25, 29, 27, 24, 51, 48,
+12, 13, 14, 15, 17, 16, 32, 34, 31, 35, 33, 30, 36, 54,128, 1,
+ 2, 3, 5, 4, 38, 40, 37, 41, 39, 50, 56, 42, 6, 7, 8, 9,
+11, 45, 46, 43, 47, 44,123, 67, 58, 49, 57,122,120, 99,118, 96,
+97, 98,100,101,109, 71,107, 89, 91, 92, 78, 86, 87, 88, 69, 83,
+84, 85, 82, 65, 42, 0, 10,103,111, 0, 0, 0, 0, 0, 0, 0,
+76,125, 75,105,124,110,115, 62,116, 59, 60,119, 61,121,114,117,
+ 0, 0, 0, 0,127, 81, 0,113, 0, 0, 0, 0, 95, 55, 55, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 94, 0, 93, 0, 0, 0, 0, 0, 0,104,102 };
+#endif /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
+
static int emulate_raw(unsigned int keycode, int down)
{
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+ if (mac_hid_mouse_emulate_buttons(1, keycode, down))
+ return 0;
+#endif /* CONFIG_MAC_EMUMOUSEBTN */
+#if defined(CONFIG_MAC_ADBKEYCODES) || defined(CONFIG_ADB_KEYBOARD)
+ if (!mac_hid_keyboard_sends_linux_keycodes()) {
+ if (keycode 255 || !mac_keycodes[keycode])
+ return -1;
+
+ handle_scancode((mac_keycodes[keycode] 0x7f), down);
+ return 0;
+ }
+#endif /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
+
if (keycode 255 || !x86_keycodes[keycode])
return -1;
@@ -89,30 +127,7 @@ static int emulate_raw(unsigned int keyc
return 0;
}
-
-#elif defined(CONFIG_ADB_KEYBOARD)
-
-static unsigned char mac_keycodes[128] =
- { 0, 53, 18, 19, 20, 21, 23, 22, 26, 28, 25, 29, 27, 24, 51, 48,
-12, 13, 14, 15, 17, 16, 32, 34, 31, 35, 33, 30, 36, 54,128, 1,
- 2, 3, 5, 4, 38, 40, 37, 41, 39, 50, 56, 42, 6, 7, 8, 9,
-11, 45, 46, 43, 47, 44,123, 67, 58, 49, 57,122,120, 99,118, 96,
-97, 98,100,101,109, 71,107, 89, 91, 92, 78, 86, 87, 88, 69, 83,
-84, 85, 82, 65, 42, 0, 10,103,111, 0, 0, 0, 0, 0, 0, 0,
-76,125, 75,105,124, 0,115, 62,116, 59, 60,119, 61,121,114,117,
- 0, 0, 0, 0,127, 81, 0,113, 0, 0, 0, 0, 0, 55, 55 };
-
-static int emulate_raw(unsigned int keycode, int down)
-{
- if (keycode 127 || !mac_keycodes[keycode])
- return -1;
-
- handle_scancode(mac_keycodes[keycode] 0x7f, down);
-
-
Re: asm-ppc/elf.h error
At 22:07 24.11.00, David Riley wrote: >In asm-ppc/elf.h, is not included. This breaks >compilations of anything that compiles it (e.g. binutils) because the >vector registers for Altivec aren't defined elsewhere. Included is a >quick diff. I didn't know which PPC maintainer to send this to, so I >posted it to the linuxppc-dev list. (Looking at the correct patch) Why do you need that? Your claim that binutils needs that is simply wrong, I compiled CVS binutils without problems against bk 2.4.0-t11. In any case, glibc-2.1.3 and glibc-2.2 have this stuff in sys/procfs.h, so you should use that instead I guess. That's at least what gdb uses. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: asm-ppc/elf.h error
At 22:07 24.11.00, David Riley wrote: In asm-ppc/elf.h, asm/types.h is not included. This breaks compilations of anything that compiles it (e.g. binutils) because the vector registers for Altivec aren't defined elsewhere. Included is a quick diff. I didn't know which PPC maintainer to send this to, so I posted it to the linuxppc-dev list. (Looking at the correct patch) Why do you need that? Your claim that binutils needs that is simply wrong, I compiled CVS binutils without problems against bk 2.4.0-t11. In any case, glibc-2.1.3 and glibc-2.2 have this stuff in sys/procfs.h, so you should use that instead I guess. That's at least what gdb uses. Franz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
At 17:03 07.09.00, Andrea Arcangeli wrote:
>On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
>I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
>memory (it looks necessary to make sure the compiler doesn't delay to
>write data to the memory out of the critical section).
>
>And in practice I can't reproduce any corruption with any subtle testcase
>by removing "memory" from the clobber list of all the
>spinlocks/__sti/__cli, so it may be the other way around. Maybe we can
>rely on the __volatile__ statement of the asm that will enforce that if we
>write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
>in the assembler we'll then find both a write of 0 and then a write of 1
>to memory. I'd say with the current compiler we can rely on it (infact the
>spinlock doesn't seems to get miscompiled at the moment even while they
>aren't clobbering "memory".
>
>Same with:
>
> int a = *p;
> __asm__ __volatile__("" : :);
> a = *p;
>
>(to do two explicit reads)
>
>If "memory" isn't necessary in spin_lock, then all the "memory" clobbers
>around include/*/* (also in mb() and __cli() and even barrier()) are not
>necessary. But then "why" we need a "memory" clobber in first place if the
>"memory" isn't necessary? :)) Also the gcc documentation seems to say we
>need "memory" in all such operations (also in __sti() and
>spin_unlock() unlike I said in my earlier email).
>
>I'd like if some compiler guy could comment (I got no one reply yet). I
>tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
>implement semantics of the "memory" clobber fast (though I would
>appreciate a pointer in the gcc sources to start to understand some gcc
>code :).
In short terms:
- __volatile__ assures that the code isn't reordered against other
__volatile__ and isn't hoisted out of loops, nothing else
- the "memory" clobber makes sure the asm isn't reordered against other
memory accesses
Essentially, you _always_ have to tell the compiler if you touch memory
behind it's back, this includes inline assembly to flush the cache or the
write back queue. Since you usually don't know which part of the memory
gets touched, you need the global "memory" clobber. If you know which
addresses you touch, you can get away with something like this, from
asm-ppc/io.h:
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1; eieio" : "=r" (ret) : "m"
(*addr));
return ret;
}
extern inline void out_le32(volatile unsigned *addr, int val)
{
__asm__ __volatile__("stwbrx %1,0,%2; eieio" : "=m" (*addr) :
"r" (val), "r" (addr));
}
General rule of thumb for inline assembly:
Give the compiler as much information as possible!!
If you know inline assembly read/writes memory, tell it to the compiler, as
detailed as possible!
Franz.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
At 17:03 07.09.00, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doesn't delay to
write data to the memory out of the critical section).
And in practice I can't reproduce any corruption with any subtle testcase
by removing "memory" from the clobber list of all the
spinlocks/__sti/__cli, so it may be the other way around. Maybe we can
rely on the __volatile__ statement of the asm that will enforce that if we
write:
*p = 0;
__asm__ __volatile__("" : :);
*p = 1;
in the assembler we'll then find both a write of 0 and then a write of 1
to memory. I'd say with the current compiler we can rely on it (infact the
spinlock doesn't seems to get miscompiled at the moment even while they
aren't clobbering "memory".
Same with:
int a = *p;
__asm__ __volatile__("" : :);
a = *p;
(to do two explicit reads)
If "memory" isn't necessary in spin_lock, then all the "memory" clobbers
around include/*/* (also in mb() and __cli() and even barrier()) are not
necessary. But then "why" we need a "memory" clobber in first place if the
"memory" isn't necessary? :)) Also the gcc documentation seems to say we
need "memory" in all such operations (also in __sti() and
spin_unlock() unlike I said in my earlier email).
I'd like if some compiler guy could comment (I got no one reply yet). I
tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
implement semantics of the "memory" clobber fast (though I would
appreciate a pointer in the gcc sources to start to understand some gcc
code :).
In short terms:
- __volatile__ assures that the code isn't reordered against other
__volatile__ and isn't hoisted out of loops, nothing else
- the "memory" clobber makes sure the asm isn't reordered against other
memory accesses
Essentially, you _always_ have to tell the compiler if you touch memory
behind it's back, this includes inline assembly to flush the cache or the
write back queue. Since you usually don't know which part of the memory
gets touched, you need the global "memory" clobber. If you know which
addresses you touch, you can get away with something like this, from
asm-ppc/io.h:
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1; eieio" : "=r" (ret) : "m"
(*addr));
return ret;
}
extern inline void out_le32(volatile unsigned *addr, int val)
{
__asm__ __volatile__("stwbrx %1,0,%2; eieio" : "=m" (*addr) :
"r" (val), "r" (addr));
}
General rule of thumb for inline assembly:
Give the compiler as much information as possible!!
If you know inline assembly read/writes memory, tell it to the compiler, as
detailed as possible!
Franz.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] t8p1: Fix input driver configuration
Resent as per Linus request. Franz. Hi, the attached patch does the following: * move input/Config.in in front of char/Config.in in all arch/*/config.in (already done in t7p7 for x86) * fix a small uncleanliness in char/keyboard.c, replace plain_map with key_maps[0] to enable correct runtime switching of tables * update keycode translation table in input/keybdev.c (checked with Vojtech) Linus, please apply. Franz. diff -uprN linux-2.4.0-test7-pre7-clean/arch/alpha/config.in linux-2.4.0-test7-pre7/arch/alpha/config.in --- linux-2.4.0-test7-pre7-clean/arch/alpha/config.in Tue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/alpha/config.in Wed Aug 23 20:10:21 2000 @@ -300,6 +300,8 @@ if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; t fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -335,7 +337,6 @@ fi endmenu source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/arm/config.in linux-2.4.0-test7-pre7/arch/arm/config.in --- linux-2.4.0-test7-pre7-clean/arch/arm/config.in Tue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/arm/config.in Wed Aug 23 20:11:02 2000 @@ -312,6 +312,8 @@ if [ "$CONFIG_ISDN" != "n" ]; then fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in if [ "$CONFIG_ARCH_ACORN" = "y" -a \ "$CONFIG_BUSMOUSE" = "y" ]; then @@ -354,8 +356,6 @@ if [ "$CONFIG_ARCH_ACORN" = "y" -o \ fi source drivers/usb/Config.in -source drivers/input/Config.in - mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/ia64/config.in linux-2.4.0-test7-pre7/arch/ia64/config.in --- linux-2.4.0-test7-pre7-clean/arch/ia64/config.inTue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/ia64/config.in Wed Aug 23 20:12:08 2000 @@ -160,6 +160,8 @@ endmenu fi # !HP_SIM +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -191,7 +193,6 @@ fi endmenu source drivers/usb/Config.in -source drivers/input/Config.in fi # !HP_SIM diff -uprN linux-2.4.0-test7-pre7-clean/arch/mips/config.in linux-2.4.0-test7-pre7/arch/mips/config.in --- linux-2.4.0-test7-pre7-clean/arch/mips/config.inTue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/mips/config.in Wed Aug 23 20:13:27 2000 @@ -293,6 +293,8 @@ if [ "$CONFIG_ISA" = "y" -o "$CONFIG_PCI endmenu fi +source drivers/input/Config.in + if [ "$CONFIG_DECSTATION" != "y" -a \ "$CONFIG_SGI_IP22" != "y" ]; then source drivers/char/Config.in @@ -378,7 +380,6 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/mips64/config.in linux-2.4.0-test7-pre7/arch/mips64/config.in --- linux-2.4.0-test7-pre7-clean/arch/mips64/config.in Tue Aug 22 23:50:40 2000 +++ linux-2.4.0-test7-pre7/arch/mips64/config.inWed Aug 23 20:14:08 2000 @@ -208,6 +208,8 @@ if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; t fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -248,7 +250,6 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/ppc/config.in linux-2.4.0-test7-pre7/arch/ppc/config.in --- linux-2.4.0-test7-pre7-clean/arch/ppc/config.in Tue Aug 22 23:50:40 2000 +++ linux-2.4.0-test7-pre7/arch/ppc/config.in Wed Aug 23 20:14:32 2000 @@ -262,6 +262,8 @@ comment 'Console drivers' source drivers/video/Config.in endmenu +source drivers/input/Config.in + source drivers/char/Config.in source drivers/media/Config.in @@ -287,7 +289,6 @@ source arch/ppc/8260_io/Config.in fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/drivers/char/keyboard.c linux-2.4.0-test7-pre7/drivers/char/keyboard.c --- linux-2.4.0-test7-pre7-clean/drivers/char/keyboard.cTue Aug 1 04:36:10 2000 +++ linux-2.4.0-test7-pre7/drivers/char/keyboard.c Wed Aug 23 20:06:21 2000 @@ -322,7 +322,7 @@ void handle_scancode(unsigned char scanc compute_shiftstate(); kbd->slockstate = 0; /* play it safe */ #else - keysym = U(plain_map[keycode]); + keysym = U(key_maps[0][keycode]); type = KTYP(keysym); if (type == KT_SHIFT) (*key_handler[type])(keysym & 0xff, up_flag); @@ -750,7 +750,7 @@ void compute_shiftstate(void) k = i*BITS_PER_LONG; for(j=0; j
[PATCH] t8p1: Fix input driver configuration
Resent as per Linus request. Franz. Hi, the attached patch does the following: * move input/Config.in in front of char/Config.in in all arch/*/config.in (already done in t7p7 for x86) * fix a small uncleanliness in char/keyboard.c, replace plain_map with key_maps[0] to enable correct runtime switching of tables * update keycode translation table in input/keybdev.c (checked with Vojtech) Linus, please apply. Franz. diff -uprN linux-2.4.0-test7-pre7-clean/arch/alpha/config.in linux-2.4.0-test7-pre7/arch/alpha/config.in --- linux-2.4.0-test7-pre7-clean/arch/alpha/config.in Tue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/alpha/config.in Wed Aug 23 20:10:21 2000 @@ -300,6 +300,8 @@ if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; t fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -335,7 +337,6 @@ fi endmenu source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/arm/config.in linux-2.4.0-test7-pre7/arch/arm/config.in --- linux-2.4.0-test7-pre7-clean/arch/arm/config.in Tue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/arm/config.in Wed Aug 23 20:11:02 2000 @@ -312,6 +312,8 @@ if [ "$CONFIG_ISDN" != "n" ]; then fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in if [ "$CONFIG_ARCH_ACORN" = "y" -a \ "$CONFIG_BUSMOUSE" = "y" ]; then @@ -354,8 +356,6 @@ if [ "$CONFIG_ARCH_ACORN" = "y" -o \ fi source drivers/usb/Config.in -source drivers/input/Config.in - mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/ia64/config.in linux-2.4.0-test7-pre7/arch/ia64/config.in --- linux-2.4.0-test7-pre7-clean/arch/ia64/config.inTue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/ia64/config.in Wed Aug 23 20:12:08 2000 @@ -160,6 +160,8 @@ endmenu fi # !HP_SIM +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -191,7 +193,6 @@ fi endmenu source drivers/usb/Config.in -source drivers/input/Config.in fi # !HP_SIM diff -uprN linux-2.4.0-test7-pre7-clean/arch/mips/config.in linux-2.4.0-test7-pre7/arch/mips/config.in --- linux-2.4.0-test7-pre7-clean/arch/mips/config.inTue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/mips/config.in Wed Aug 23 20:13:27 2000 @@ -293,6 +293,8 @@ if [ "$CONFIG_ISA" = "y" -o "$CONFIG_PCI endmenu fi +source drivers/input/Config.in + if [ "$CONFIG_DECSTATION" != "y" -a \ "$CONFIG_SGI_IP22" != "y" ]; then source drivers/char/Config.in @@ -378,7 +380,6 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/mips64/config.in linux-2.4.0-test7-pre7/arch/mips64/config.in --- linux-2.4.0-test7-pre7-clean/arch/mips64/config.in Tue Aug 22 23:50:40 2000 +++ linux-2.4.0-test7-pre7/arch/mips64/config.inWed Aug 23 20:14:08 2000 @@ -208,6 +208,8 @@ if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; t fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -248,7 +250,6 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/ppc/config.in linux-2.4.0-test7-pre7/arch/ppc/config.in --- linux-2.4.0-test7-pre7-clean/arch/ppc/config.in Tue Aug 22 23:50:40 2000 +++ linux-2.4.0-test7-pre7/arch/ppc/config.in Wed Aug 23 20:14:32 2000 @@ -262,6 +262,8 @@ comment 'Console drivers' source drivers/video/Config.in endmenu +source drivers/input/Config.in + source drivers/char/Config.in source drivers/media/Config.in @@ -287,7 +289,6 @@ source arch/ppc/8260_io/Config.in fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/drivers/char/keyboard.c linux-2.4.0-test7-pre7/drivers/char/keyboard.c --- linux-2.4.0-test7-pre7-clean/drivers/char/keyboard.cTue Aug 1 04:36:10 2000 +++ linux-2.4.0-test7-pre7/drivers/char/keyboard.c Wed Aug 23 20:06:21 2000 @@ -322,7 +322,7 @@ void handle_scancode(unsigned char scanc compute_shiftstate(); kbd-slockstate = 0; /* play it safe */ #else - keysym = U(plain_map[keycode]); + keysym = U(key_maps[0][keycode]); type = KTYP(keysym); if (type == KT_SHIFT) (*key_handler[type])(keysym 0xff, up_flag); @@ -750,7 +750,7 @@ void compute_shiftstate(void) k = i*BITS_PER_LONG; for(j=0; jBITS_PER_LONG; j++,k++)
