修改内核路径

hc

2024-05-14 bedbef8ad3e75a304af6361af235302bcc61d06b

 kernel/arch/parisc/include/asm/ldcw.h
..
..
@@ -2,14 +2,28 @@
2
2
 #ifndef __PARISC_LDCW_H
3
3
 #define __PARISC_LDCW_H
4
4
 
5
-#ifndef CONFIG_PA20
6
5
 /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data,
7
6
    and GCC only guarantees 8-byte alignment for stack locals, we can't
8
7
    be assured of 16-byte alignment for atomic lock data even if we
9
8
    specify "__attribute ((aligned(16)))" in the type declaration.  So,
10
9
    we use a struct containing an array of four ints for the atomic lock
11
10
    type and dynamically select the 16-byte aligned int from the array
12
-   for the semaphore.  */
11
+   for the semaphore. */
12
+
13
+/* From: "Jim Hull" <jim.hull of hp.com>
14
+   I've attached a summary of the change, but basically, for PA 2.0, as
15
+   long as the ",CO" (coherent operation) completer is implemented, then the
16
+   16-byte alignment requirement for ldcw and ldcd is relaxed, and instead
17
+   they only require "natural" alignment (4-byte for ldcw, 8-byte for
18
+   ldcd).
19
+
20
+   Although the cache control hint is accepted by all PA 2.0 processors,
21
+   it is only implemented on PA8800/PA8900 CPUs. Prior PA8X00 CPUs still
22
+   require 16-byte alignment. If the address is unaligned, the operation
23
+   of the instruction is undefined. The ldcw instruction does not generate
24
+   unaligned data reference traps so misaligned accesses are not detected.
25
+   This hid the problem for years. So, restore the 16-byte alignment dropped
26
+   by Kyle McMartin in "Remove __ldcw_align for PA-RISC 2.0 processors". */
13
27
 
14
28
 #define __PA_LDCW_ALIGNMENT	16
15
29
 #define __PA_LDCW_ALIGN_ORDER	4
..
..
@@ -19,22 +33,12 @@
19
33
 		& ~(__PA_LDCW_ALIGNMENT - 1);			\
20
34
 	(volatile unsigned int *) __ret;			\
21
35
 })
22
-#define __LDCW	"ldcw"
23
36
 
24
-#else /*CONFIG_PA20*/
25
-/* From: "Jim Hull" <jim.hull of hp.com>
26
-   I've attached a summary of the change, but basically, for PA 2.0, as
27
-   long as the ",CO" (coherent operation) completer is specified, then the
28
-   16-byte alignment requirement for ldcw and ldcd is relaxed, and instead
29
-   they only require "natural" alignment (4-byte for ldcw, 8-byte for
30
-   ldcd). */
31
-
32
-#define __PA_LDCW_ALIGNMENT	4
33
-#define __PA_LDCW_ALIGN_ORDER	2
34
-#define __ldcw_align(a) (&(a)->slock)
37
+#ifdef CONFIG_PA20
35
38
 #define __LDCW	"ldcw,co"
36
-
37
-#endif /*!CONFIG_PA20*/
39
+#else
40
+#define __LDCW	"ldcw"
41
+#endif
38
42
 
39
43
 /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*.
40
44
    We don't explicitly expose that "*a" may be written as reload
..
..
@@ -52,7 +56,7 @@
52
56
 })
53
57
 
54
58
 #ifdef CONFIG_SMP
55
-# define __lock_aligned __attribute__((__section__(".data..lock_aligned")))
59
+# define __lock_aligned __section(".data..lock_aligned")
56
60
 #endif
57
61
 
58
62
 #endif /* __PARISC_LDCW_H */