hc
2024-01-05 071106ecf68c401173c58808b1cf5f68cc50d390
kernel/arch/parisc/include/asm/ldcw.h
....@@ -2,14 +2,28 @@
22 #ifndef __PARISC_LDCW_H
33 #define __PARISC_LDCW_H
44
5
-#ifndef CONFIG_PA20
65 /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data,
76 and GCC only guarantees 8-byte alignment for stack locals, we can't
87 be assured of 16-byte alignment for atomic lock data even if we
98 specify "__attribute ((aligned(16)))" in the type declaration. So,
109 we use a struct containing an array of four ints for the atomic lock
1110 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". */
1327
1428 #define __PA_LDCW_ALIGNMENT 16
1529 #define __PA_LDCW_ALIGN_ORDER 4
....@@ -19,22 +33,12 @@
1933 & ~(__PA_LDCW_ALIGNMENT - 1); \
2034 (volatile unsigned int *) __ret; \
2135 })
22
-#define __LDCW "ldcw"
2336
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
3538 #define __LDCW "ldcw,co"
36
-
37
-#endif /*!CONFIG_PA20*/
39
+#else
40
+#define __LDCW "ldcw"
41
+#endif
3842
3943 /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*.
4044 We don't explicitly expose that "*a" may be written as reload