cpufreq: pcc: fix use-after-free and double free in _OSC evaluation

PATCH Superseded Yuho Choi 3 participants 4 messages Apr 15 – May 1 CPU frequency scaling framework

Share & tools

Yuho Choi

author

2026-04-15 16:51 UTC #0 lore raw

PATCH 1/1 cpufreq: pcc: fix use-after-free and double free in _OSC evaluation

pcc_cpufreq_do_osc() evaluates _OSC twice with the same output buffer. The first acpi_evaluate_object() allocates the buffer because output is initialized with ACPI_ALLOCATE_BUFFER. Freeing output.pointer before the second evaluation leaves output.length stale, so the next call treats output as a caller-supplied buffer and performs a use-after-free write into the freed memory. The final cleanup path then frees the same pointer again, causing a double free.

Keep the first _OSC result alive until the shared cleanup path and route the early error exits through out_free. This avoids both the use-after- free on the second evaluation and the final double free.

Fixes 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")

Signed-off-by Yuho Choi <[email protected]>

---
 drivers/cpufreq/pcc-cpufreq.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/cpufreq/pcc-cpufreq.c +9 -5

index ac2e90a65f0c4..165826b5d6844 100644
@@ -23,6 +23,7 @@
  * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  */
 
+#include "acpi/actypes.h"
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>

@@ -351,16 +352,19 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
 		goto out_free;
 	}
 
-	kfree(output.pointer);
 	capabilities[0] = 0x0;
 	capabilities[1] = 0x1;
 
 	status = acpi_evaluate_object(*handle, "_OSC", &input, &output);
-	if (ACPI_FAILURE(status))
-		return -ENODEV;
+	if (ACPI_FAILURE(status)) {
+		ret = -ENODEV;
+		goto out_free;
+	}
 
-	if (!output.length)
-		return -ENODEV;
+	if (!output.length) {
+		ret = -ENODEV;
+		goto out_free;
+	}
 
 	out_obj = output.pointer;
 	if (out_obj->type != ACPI_TYPE_BUFFER) {

Signature · 1 line

2.50.1 (Apple Git-155)

Zhongqiu Han

2026-04-16 06:04 UTC #1 lore raw

Quoted 23 lines · Yuho Choi

pcc_cpufreq_do_osc() evaluates _OSC twice with the same output buffer. The first acpi_evaluate_object() allocates the buffer because output is initialized with ACPI_ALLOCATE_BUFFER. Freeing output.pointer before the second evaluation leaves output.length stale, so the next call treats output as a caller-supplied buffer and performs a use-after-free write into the freed memory. The final cleanup path then frees the same pointer again, causing a double free.
Keep the first _OSC result alive until the shared cleanup path and route the early error exits through out_free. This avoids both the use-after- free on the second evaluation and the final double free.
Fixes 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
Signed-off-by Yuho Choi <[email protected]>
---
  drivers/cpufreq/pcc-cpufreq.c | 14 +++++++++-----
  1 file changed, 9 insertions(+), 5 deletions(-)
drivers/cpufreq/pcc-cpufreq.c +0 -0
index ac2e90a65f0c4..165826b5d6844 100644

drivers/cpufreq/pcc-cpufreq.c line 24

Quoted 2 lines

drivers/cpufreq/pcc-cpufreq.c +0 -0

@@ -23,6 +23,7 @@
   * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   */

Hi Yuho Choi,
Thanks for the patch.

drivers/cpufreq/pcc-cpufreq.c line 26

Quoted 2 lines

drivers/cpufreq/pcc-cpufreq.c +1 -0
+#include "acpi/actypes.h"

1.I don't see why this header is needed for this change. Even if it is, it’s already included by <linux/acpi.h>, right?

drivers/cpufreq/pcc-cpufreq.c static int __init pcc_cpufreq_do_osc(acpi_handle *handle) · line 354

Quoted 8 lines

drivers/cpufreq/pcc-cpufreq.c +0 -1

  #include <linux/kernel.h>
  #include <linux/module.h>
  #include <linux/init.h>

@@ -351,16 +352,19 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
  		goto out_free;
  	}
 
-	kfree(output.pointer);

2.Would it be cleaner to reset the pointer and output.length, and let acpi_evaluate_object() reallocate the buffer? For example:

        kfree(output.pointer);

+ output.pointer = NULL;
+ output.length = ACPI_ALLOCATE_BUFFER;

3.The sashiko.dev pointed out a few pre-existing boundary checking issues that are outside the scope of this patch.

https://sashiko.dev/#/patchset/20260415165139.14113-1-dbgh9129%40gmail.com

Quoted 20 lines

drivers/cpufreq/pcc-cpufreq.c +8 -4

  	capabilities[0] = 0x0;
  	capabilities[1] = 0x1;
 
  	status = acpi_evaluate_object(*handle, "_OSC", &input, &output);
-	if (ACPI_FAILURE(status))
-		return -ENODEV;
+	if (ACPI_FAILURE(status)) {
+		ret = -ENODEV;
+		goto out_free;
+	}
 
-	if (!output.length)
-		return -ENODEV;
+	if (!output.length) {
+		ret = -ENODEV;
+		goto out_free;
+	}
 
  	out_obj = output.pointer;
  	if (out_obj->type != ACPI_TYPE_BUFFER) {

Signature · 2 lines

Thx and BRs,
Zhongqiu Han

최유호

author

2026-04-16 14:31 UTC #2 lore raw

Dear Zhongqiu Han,

Quoted 2 lines

1. I don't see why this header is needed for this change. Even if it is, it's already included by <linux/acpi.h>, right?

You are right, it is unnecessary. I will drop it in v2.

Quoted 2 lines

2. Would it be cleaner to reset the pointer and output.length, and let acpi_evaluate_object() reallocate the buffer?

Agreed, that is cleaner and makes the intent explicit. I will adopt your suggestion in v2.

Quoted 2 lines

3. The sashiko.dev pointed out a few pre-existing boundary checking issues that are outside the scope of this patch.

Noted. I will address those in a separate patch.

Thanks for the review.

Best regards,
Yuho Choi

Quoted 85 lines · Zhongqiu Han

Quoted 23 lines · Yuho Choi
pcc_cpufreq_do_osc() evaluates _OSC twice with the same output buffer. The first acpi_evaluate_object() allocates the buffer because output is initialized with ACPI_ALLOCATE_BUFFER. Freeing output.pointer before the second evaluation leaves output.length stale, so the next call treats output as a caller-supplied buffer and performs a use-after-free write into the freed memory. The final cleanup path then frees the same pointer again, causing a double free.
Keep the first _OSC result alive until the shared cleanup path and route the early error exits through out_free. This avoids both the use-after- free on the second evaluation and the final double free.
Fixes 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
Signed-off-by Yuho Choi <[email protected]>
---
  drivers/cpufreq/pcc-cpufreq.c | 14 +++++++++-----
  1 file changed, 9 insertions(+), 5 deletions(-)
drivers/cpufreq/pcc-cpufreq.c +0 -0
index ac2e90a65f0c4..165826b5d6844 100644
drivers/cpufreq/pcc-cpufreq.c line 24
Quoted 2 lines
drivers/cpufreq/pcc-cpufreq.c +0 -0
@@ -23,6 +23,7 @@
   * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   */
Hi Yuho Choi,
Thanks for the patch.
drivers/cpufreq/pcc-cpufreq.c line 26
Quoted 2 lines
drivers/cpufreq/pcc-cpufreq.c +1 -0
+#include "acpi/actypes.h"
1.I don't see why this header is needed for this change. Even if it is, it’s already included by <linux/acpi.h>, right?
drivers/cpufreq/pcc-cpufreq.c static int __init pcc_cpufreq_do_osc(acpi_handle *handle) · line 354
Quoted 8 lines
drivers/cpufreq/pcc-cpufreq.c +0 -1
  #include <linux/kernel.h>
  #include <linux/module.h>
  #include <linux/init.h>
@@ -351,16 +352,19 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
              goto out_free;
      }
 
-     kfree(output.pointer);
2.Would it be cleaner to reset the pointer and output.length, and let acpi_evaluate_object() reallocate the buffer? For example:
         kfree(output.pointer);
(quoted diff) +2 -0
+       output.pointer = NULL;
+       output.length = ACPI_ALLOCATE_BUFFER;
3.The sashiko.dev pointed out a few pre-existing boundary checking issues that are outside the scope of this patch.
https://sashiko.dev/#/patchset/20260415165139.14113-1-dbgh9129%40gmail.com
Quoted 10 lines
drivers/cpufreq/pcc-cpufreq.c +4 -2
      capabilities[0] = 0x0;
      capabilities[1] = 0x1;
 
      status = acpi_evaluate_object(*handle, "_OSC", &input, &output);
-     if (ACPI_FAILURE(status))
-             return -ENODEV;
+     if (ACPI_FAILURE(status)) {
+             ret = -ENODEV;
+             goto out_free;
+     }
drivers/cpufreq/pcc-cpufreq.c static int __init pcc_cpufreq_do_osc(acpi_handle *handle) · line 370
Quoted 10 lines
drivers/cpufreq/pcc-cpufreq.c +4 -2
 
-     if (!output.length)
-             return -ENODEV;
+     if (!output.length) {
+             ret = -ENODEV;
+             goto out_free;
+     }
 
      out_obj = output.pointer;
      if (out_obj->type != ACPI_TYPE_BUFFER) {
--
Thx and BRs,
Zhongqiu Han

kernel test robot

build bot

2026-05-01 18:40 UTC #3 lore raw

In reply to Yuho Choi

kernel test robot noticed the following build errors:

Hi Yuho,

kernel test robot noticed the following build errors:

[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/bleeding-edge linus/master v7.1-rc1 next-20260430] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Yuho-Choi/cpufreq-pcc-fix-use-after-free-and-double-free-in-_OSC-evaluation/20260418-135954
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20260415165139.14113-1-dbgh9129%40gmail.com
patch subject: [PATCH v1] cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20260502/[email protected]/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260502/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

In file included from drivers/cpufreq/pcc-cpufreq.c:26:

>> include/acpi/actypes.h:21:2: error: ACPI_MACHINE_WIDTH not defined
      21 | #error ACPI_MACHINE_WIDTH not defined
         |  ^
   include/acpi/actypes.h:95:9: error: unknown type name 'COMPILER_DEPENDENT_UINT64'
      95 | typedef COMPILER_DEPENDENT_UINT64 u64;
         |         ^
   include/acpi/actypes.h:96:9: error: unknown type name 'COMPILER_DEPENDENT_INT64'
      96 | typedef COMPILER_DEPENDENT_INT64 s64;
         |         ^
   include/acpi/actypes.h:116:5: warning: 'ACPI_MACHINE_WIDTH' is not defined, evaluates to 0 [-Wundef]
     116 | #if ACPI_MACHINE_WIDTH == 64
         |     ^
   include/acpi/actypes.h:157:7: warning: 'ACPI_MACHINE_WIDTH' is not defined, evaluates to 0 [-Wundef]
     157 | #elif ACPI_MACHINE_WIDTH == 32
         |       ^
>> include/acpi/actypes.h:199:2: error: unknown ACPI_MACHINE_WIDTH
     199 | #error unknown ACPI_MACHINE_WIDTH
         |  ^
   include/acpi/actypes.h:230:6: warning: 'ACPI_MUTEX_TYPE' is not defined, evaluates to 0 [-Wundef]
     230 | #if (ACPI_MUTEX_TYPE == ACPI_BINARY_SEMAPHORE)
         |      ^
   include/acpi/actypes.h:230:25: warning: 'ACPI_BINARY_SEMAPHORE' is not defined, evaluates to 0 [-Wundef]
     230 | #if (ACPI_MUTEX_TYPE == ACPI_BINARY_SEMAPHORE)
         |                         ^
   include/acpi/actypes.h:421:9: error: unknown type name 'u32'
     421 | typedef u32 acpi_status;        /* All ACPI Exceptions */
         |         ^
   include/acpi/actypes.h:422:9: error: unknown type name 'u32'
     422 | typedef u32 acpi_name;          /* 4-byte ACPI name */
         |         ^
   include/acpi/actypes.h:644:9: error: unknown type name 'u32'
     644 | typedef u32 acpi_object_type;
         |         ^
   include/acpi/actypes.h:716:9: error: unknown type name 'u32'
     716 | typedef u32 acpi_event_type;
         |         ^
   include/acpi/actypes.h:747:9: error: unknown type name 'u32'
     747 | typedef u32 acpi_event_status;
         |         ^
   include/acpi/actypes.h:917:3: error: unknown type name 'u32'
     917 |                 u32 length;     /* # of bytes in string, excluding trailing null */
         |                 ^
   include/acpi/actypes.h:923:3: error: unknown type name 'u32'
     923 |                 u32 length;     /* # of bytes in buffer */
         |                 ^
   include/acpi/actypes.h:929:3: error: unknown type name 'u32'
     929 |                 u32 count;      /* # of elements in package */
         |                 ^
   include/acpi/actypes.h:941:3: error: unknown type name 'u32'
     941 |                 u32 proc_id;
         |                 ^
   include/acpi/actypes.h:942:3: error: unknown type name 'acpi_io_address'
     942 |                 acpi_io_address pblk_address;
         |                 ^
   include/acpi/actypes.h:943:3: error: unknown type name 'u32'
     943 |                 u32 pblk_length;
         |                 ^
   include/acpi/actypes.h:948:3: error: unknown type name 'u32'
     948 |                 u32 system_level;
         |                 ^
   include/acpi/actypes.h:949:3: error: unknown type name 'u32'
     949 |                 u32 resource_order;
         |                 ^
   include/acpi/actypes.h:957:2: error: unknown type name 'u32'
     957 |         u32 count;
         |         ^
   include/acpi/actypes.h:979:2: error: unknown type name 'acpi_size'
     979 |         acpi_size length;       /* Length in bytes of the buffer */
         |         ^

fatal error: too many errors emitted, stopping now [-ferror-limit=] 4 warnings and 20 errors generated.

vim +21 include/acpi/actypes.h

61686124f47d7c Bob Moore      2006-03-17   14  
defba1d8f233c0 Bob Moore      2005-12-16   15  /*
c6915b3f29eb09 Bob Moore      2017-06-05   16   * ACPI_MACHINE_WIDTH must be specified in an OS- or compiler-dependent
c6915b3f29eb09 Bob Moore      2017-06-05   17   * header and must be either 32 or 64. 16-bit ACPICA is no longer
c6915b3f29eb09 Bob Moore      2017-06-05   18   * supported, as of 12/2006.
defba1d8f233c0 Bob Moore      2005-12-16   19   */
defba1d8f233c0 Bob Moore      2005-12-16   20  #ifndef ACPI_MACHINE_WIDTH
defba1d8f233c0 Bob Moore      2005-12-16  @21  #error ACPI_MACHINE_WIDTH not defined
defba1d8f233c0 Bob Moore      2005-12-16   22  #endif
defba1d8f233c0 Bob Moore      2005-12-16   23  
^1da177e4c3f41 Linus Torvalds 2005-04-16   24  /*
^1da177e4c3f41 Linus Torvalds 2005-04-16   25   * Data type ranges
^1da177e4c3f41 Linus Torvalds 2005-04-16   26   * Note: These macros are designed to be compiler independent as well as
^1da177e4c3f41 Linus Torvalds 2005-04-16   27   * working around problems that some 32-bit compilers have with 64-bit
^1da177e4c3f41 Linus Torvalds 2005-04-16   28   * constants.
^1da177e4c3f41 Linus Torvalds 2005-04-16   29   */
e252652fb2664d Lv Zheng       2014-02-11   30  #define ACPI_UINT8_MAX                  (u8) (~((u8)  0))	/* 0xFF               */
e252652fb2664d Lv Zheng       2014-02-11   31  #define ACPI_UINT16_MAX                 (u16)(~((u16) 0))	/* 0xFFFF             */
e252652fb2664d Lv Zheng       2014-02-11   32  #define ACPI_UINT32_MAX                 (u32)(~((u32) 0))	/* 0xFFFFFFFF         */
e252652fb2664d Lv Zheng       2014-02-11   33  #define ACPI_UINT64_MAX                 (u64)(~((u64) 0))	/* 0xFFFFFFFFFFFFFFFF */
^1da177e4c3f41 Linus Torvalds 2005-04-16   34  #define ACPI_ASCII_MAX                  0x7F
^1da177e4c3f41 Linus Torvalds 2005-04-16   35  
^1da177e4c3f41 Linus Torvalds 2005-04-16   36  /*
defba1d8f233c0 Bob Moore      2005-12-16   37   * Architecture-specific ACPICA Subsystem Data Types
defba1d8f233c0 Bob Moore      2005-12-16   38   *
defba1d8f233c0 Bob Moore      2005-12-16   39   * The goal of these types is to provide source code portability across
defba1d8f233c0 Bob Moore      2005-12-16   40   * 16-bit, 32-bit, and 64-bit targets.
defba1d8f233c0 Bob Moore      2005-12-16   41   *
defba1d8f233c0 Bob Moore      2005-12-16   42   * 1) The following types are of fixed size for all targets (16/32/64):
defba1d8f233c0 Bob Moore      2005-12-16   43   *
e252652fb2664d Lv Zheng       2014-02-11   44   * u8           Logical boolean
^1da177e4c3f41 Linus Torvalds 2005-04-16   45   *
e252652fb2664d Lv Zheng       2014-02-11   46   * u8           8-bit  (1 byte) unsigned value
e252652fb2664d Lv Zheng       2014-02-11   47   * u16          16-bit (2 byte) unsigned value
e252652fb2664d Lv Zheng       2014-02-11   48   * u32          32-bit (4 byte) unsigned value
e252652fb2664d Lv Zheng       2014-02-11   49   * u64          64-bit (8 byte) unsigned value
defba1d8f233c0 Bob Moore      2005-12-16   50   *
e252652fb2664d Lv Zheng       2014-02-11   51   * s16          16-bit (2 byte) signed value
e252652fb2664d Lv Zheng       2014-02-11   52   * s32          32-bit (4 byte) signed value
e252652fb2664d Lv Zheng       2014-02-11   53   * s64          64-bit (8 byte) signed value
defba1d8f233c0 Bob Moore      2005-12-16   54   *
e252652fb2664d Lv Zheng       2014-02-11   55   * COMPILER_DEPENDENT_UINT64/s64 - These types are defined in the
c6915b3f29eb09 Bob Moore      2017-06-05   56   * compiler-dependent header(s) and were introduced because there is no
c6915b3f29eb09 Bob Moore      2017-06-05   57   * common 64-bit integer type across the various compilation models, as
c6915b3f29eb09 Bob Moore      2017-06-05   58   * shown in the table below.
defba1d8f233c0 Bob Moore      2005-12-16   59   *
defba1d8f233c0 Bob Moore      2005-12-16   60   * Datatype  LP64 ILP64 LLP64 ILP32 LP32 16bit
defba1d8f233c0 Bob Moore      2005-12-16   61   * char      8    8     8     8     8    8
defba1d8f233c0 Bob Moore      2005-12-16   62   * short     16   16    16    16    16   16
defba1d8f233c0 Bob Moore      2005-12-16   63   * _int32         32
defba1d8f233c0 Bob Moore      2005-12-16   64   * int       32   64    32    32    16   16
defba1d8f233c0 Bob Moore      2005-12-16   65   * long      64   64    32    32    32   32
defba1d8f233c0 Bob Moore      2005-12-16   66   * long long            64    64
defba1d8f233c0 Bob Moore      2005-12-16   67   * pointer   64   64    64    32    32   32
defba1d8f233c0 Bob Moore      2005-12-16   68   *
defba1d8f233c0 Bob Moore      2005-12-16   69   * Note: ILP64 and LP32 are currently not supported.
defba1d8f233c0 Bob Moore      2005-12-16   70   *
defba1d8f233c0 Bob Moore      2005-12-16   71   *
defba1d8f233c0 Bob Moore      2005-12-16   72   * 2) These types represent the native word size of the target mode of the
defba1d8f233c0 Bob Moore      2005-12-16   73   * processor, and may be 16-bit, 32-bit, or 64-bit as required. They are
defba1d8f233c0 Bob Moore      2005-12-16   74   * usually used for memory allocation, efficient loop counters, and array
c6915b3f29eb09 Bob Moore      2017-06-05   75   * indexes. The types are similar to the size_t type in the C library and
c6915b3f29eb09 Bob Moore      2017-06-05   76   * are required because there is no C type that consistently represents the
c6915b3f29eb09 Bob Moore      2017-06-05   77   * native data width. acpi_size is needed because there is no guarantee
c6915b3f29eb09 Bob Moore      2017-06-05   78   * that a kernel-level C library is present.
defba1d8f233c0 Bob Moore      2005-12-16   79   *
e252652fb2664d Lv Zheng       2014-02-11   80   * acpi_size        16/32/64-bit unsigned value
e252652fb2664d Lv Zheng       2014-02-11   81   * acpi_native_int  16/32/64-bit signed value
^1da177e4c3f41 Linus Torvalds 2005-04-16   82   */
^1da177e4c3f41 Linus Torvalds 2005-04-16   83  
defba1d8f233c0 Bob Moore      2005-12-16   84  /*******************************************************************************
defba1d8f233c0 Bob Moore      2005-12-16   85   *
defba1d8f233c0 Bob Moore      2005-12-16   86   * Common types for all compilers, all targets
defba1d8f233c0 Bob Moore      2005-12-16   87   *
defba1d8f233c0 Bob Moore      2005-12-16   88   ******************************************************************************/
0897831bb54eb3 Bob Moore      2005-10-21   89  
e252652fb2664d Lv Zheng       2014-02-11   90  #ifndef ACPI_USE_SYSTEM_INTTYPES
e252652fb2664d Lv Zheng       2014-02-11   91  
e252652fb2664d Lv Zheng       2014-02-11   92  typedef unsigned char u8;
e252652fb2664d Lv Zheng       2014-02-11   93  typedef unsigned short u16;
80a648c12e4bda Lv Zheng       2014-07-08   94  typedef short s16;
e252652fb2664d Lv Zheng       2014-02-11   95  typedef COMPILER_DEPENDENT_UINT64 u64;
e252652fb2664d Lv Zheng       2014-02-11   96  typedef COMPILER_DEPENDENT_INT64 s64;
defba1d8f233c0 Bob Moore      2005-12-16   97  
e252652fb2664d Lv Zheng       2014-02-11   98  #endif				/* ACPI_USE_SYSTEM_INTTYPES */
defba1d8f233c0 Bob Moore      2005-12-16   99  
28eb3fcf8762a3 Lin Ming       2010-09-15  100  /*
28eb3fcf8762a3 Lin Ming       2010-09-15  101   * Value returned by acpi_os_get_thread_id. There is no standard "thread_id"
28eb3fcf8762a3 Lin Ming       2010-09-15  102   * across operating systems or even the various UNIX systems. Since ACPICA
28eb3fcf8762a3 Lin Ming       2010-09-15  103   * only needs the thread ID as a unique thread identifier, we use a u64
28eb3fcf8762a3 Lin Ming       2010-09-15  104   * as the only common data type - it will accommodate any type of pointer or
28eb3fcf8762a3 Lin Ming       2010-09-15  105   * any type of integer. It is up to the host-dependent OSL to cast the
28eb3fcf8762a3 Lin Ming       2010-09-15  106   * native thread ID type to a u64 (in acpi_os_get_thread_id).
28eb3fcf8762a3 Lin Ming       2010-09-15  107   */
28eb3fcf8762a3 Lin Ming       2010-09-15  108  #define acpi_thread_id                  u64
28eb3fcf8762a3 Lin Ming       2010-09-15  109  
defba1d8f233c0 Bob Moore      2005-12-16  110  /*******************************************************************************
defba1d8f233c0 Bob Moore      2005-12-16  111   *
defba1d8f233c0 Bob Moore      2005-12-16  112   * Types specific to 64-bit targets
defba1d8f233c0 Bob Moore      2005-12-16  113   *
defba1d8f233c0 Bob Moore      2005-12-16  114   ******************************************************************************/
^1da177e4c3f41 Linus Torvalds 2005-04-16  115  
^1da177e4c3f41 Linus Torvalds 2005-04-16  116  #if ACPI_MACHINE_WIDTH == 64
^1da177e4c3f41 Linus Torvalds 2005-04-16  117  
e252652fb2664d Lv Zheng       2014-02-11  118  #ifndef ACPI_USE_SYSTEM_INTTYPES
^1da177e4c3f41 Linus Torvalds 2005-04-16  119  
e252652fb2664d Lv Zheng       2014-02-11  120  typedef unsigned int u32;
e252652fb2664d Lv Zheng       2014-02-11  121  typedef int s32;
^1da177e4c3f41 Linus Torvalds 2005-04-16  122  
e252652fb2664d Lv Zheng       2014-02-11  123  #endif				/* ACPI_USE_SYSTEM_INTTYPES */
^1da177e4c3f41 Linus Torvalds 2005-04-16  124  
defba1d8f233c0 Bob Moore      2005-12-16  125  typedef s64 acpi_native_int;
defba1d8f233c0 Bob Moore      2005-12-16  126  
67a119f990063f Bob Moore      2008-06-10  127  typedef u64 acpi_size;
^1da177e4c3f41 Linus Torvalds 2005-04-16  128  typedef u64 acpi_io_address;
^1da177e4c3f41 Linus Torvalds 2005-04-16  129  typedef u64 acpi_physical_address;
^1da177e4c3f41 Linus Torvalds 2005-04-16  130  
^1da177e4c3f41 Linus Torvalds 2005-04-16  131  #define ACPI_MAX_PTR                    ACPI_UINT64_MAX
^1da177e4c3f41 Linus Torvalds 2005-04-16  132  #define ACPI_SIZE_MAX                   ACPI_UINT64_MAX
^1da177e4c3f41 Linus Torvalds 2005-04-16  133  
defba1d8f233c0 Bob Moore      2005-12-16  134  #define ACPI_USE_NATIVE_DIVIDE	/* Has native 64-bit integer support */
65082bfcb486ef Lv Zheng       2017-08-03  135  #define ACPI_USE_NATIVE_MATH64	/* Has native 64-bit integer support */
defba1d8f233c0 Bob Moore      2005-12-16  136  
0897831bb54eb3 Bob Moore      2005-10-21  137  /*
0897831bb54eb3 Bob Moore      2005-10-21  138   * In the case of the Itanium Processor Family (IPF), the hardware does not
c6915b3f29eb09 Bob Moore      2017-06-05  139   * support misaligned memory transfers. Set the MISALIGNMENT_NOT_SUPPORTED
c6915b3f29eb09 Bob Moore      2017-06-05  140   * flag to indicate that special precautions must be taken to avoid alignment
c6915b3f29eb09 Bob Moore      2017-06-05  141   * faults. (IA64 or ia64 is currently used by existing compilers to indicate
c6915b3f29eb09 Bob Moore      2017-06-05  142   * IPF.)
0897831bb54eb3 Bob Moore      2005-10-21  143   *
ba494beeaa69bc Bob Moore      2012-07-12  144   * Note: EM64T and other X86-64 processors support misaligned transfers,
0897831bb54eb3 Bob Moore      2005-10-21  145   * so there is no need to define this flag.
0897831bb54eb3 Bob Moore      2005-10-21  146   */
0897831bb54eb3 Bob Moore      2005-10-21  147  #if defined (__IA64__) || defined (__ia64__)
0897831bb54eb3 Bob Moore      2005-10-21  148  #define ACPI_MISALIGNMENT_NOT_SUPPORTED
0897831bb54eb3 Bob Moore      2005-10-21  149  #endif
0897831bb54eb3 Bob Moore      2005-10-21  150  
defba1d8f233c0 Bob Moore      2005-12-16  151  /*******************************************************************************
defba1d8f233c0 Bob Moore      2005-12-16  152   *
defba1d8f233c0 Bob Moore      2005-12-16  153   * Types specific to 32-bit targets
defba1d8f233c0 Bob Moore      2005-12-16  154   *
defba1d8f233c0 Bob Moore      2005-12-16  155   ******************************************************************************/
defba1d8f233c0 Bob Moore      2005-12-16  156  
defba1d8f233c0 Bob Moore      2005-12-16  157  #elif ACPI_MACHINE_WIDTH == 32
defba1d8f233c0 Bob Moore      2005-12-16  158  
e252652fb2664d Lv Zheng       2014-02-11  159  #ifndef ACPI_USE_SYSTEM_INTTYPES
defba1d8f233c0 Bob Moore      2005-12-16  160  
e252652fb2664d Lv Zheng       2014-02-11  161  typedef unsigned int u32;
e252652fb2664d Lv Zheng       2014-02-11  162  typedef int s32;
defba1d8f233c0 Bob Moore      2005-12-16  163  
e252652fb2664d Lv Zheng       2014-02-11  164  #endif				/* ACPI_USE_SYSTEM_INTTYPES */
defba1d8f233c0 Bob Moore      2005-12-16  165  
defba1d8f233c0 Bob Moore      2005-12-16  166  typedef s32 acpi_native_int;
defba1d8f233c0 Bob Moore      2005-12-16  167  
67a119f990063f Bob Moore      2008-06-10  168  typedef u32 acpi_size;
2b8760100e1de6 Lv Zheng       2015-04-13  169  
2b8760100e1de6 Lv Zheng       2015-04-13  170  #ifdef ACPI_32BIT_PHYSICAL_ADDRESS
2b8760100e1de6 Lv Zheng       2015-04-13  171  
2b8760100e1de6 Lv Zheng       2015-04-13  172  /*
2b8760100e1de6 Lv Zheng       2015-04-13  173   * OSPMs can define this to shrink the size of the structures for 32-bit
2b8760100e1de6 Lv Zheng       2015-04-13  174   * none PAE environment. ASL compiler may always define this to generate
2b8760100e1de6 Lv Zheng       2015-04-13  175   * 32-bit OSPM compliant tables.
2b8760100e1de6 Lv Zheng       2015-04-13  176   */
defba1d8f233c0 Bob Moore      2005-12-16  177  typedef u32 acpi_io_address;
f3d2e7865c8162 Bob Moore      2007-02-02  178  typedef u32 acpi_physical_address;
defba1d8f233c0 Bob Moore      2005-12-16  179  
2b8760100e1de6 Lv Zheng       2015-04-13  180  #else				/* ACPI_32BIT_PHYSICAL_ADDRESS */
2b8760100e1de6 Lv Zheng       2015-04-13  181  
2b8760100e1de6 Lv Zheng       2015-04-13  182  /*
2b8760100e1de6 Lv Zheng       2015-04-13  183   * It is reported that, after some calculations, the physical addresses can
2b8760100e1de6 Lv Zheng       2015-04-13  184   * wrap over the 32-bit boundary on 32-bit PAE environment.
2b8760100e1de6 Lv Zheng       2015-04-13  185   * https://bugzilla.kernel.org/show_bug.cgi?id=87971
2b8760100e1de6 Lv Zheng       2015-04-13  186   */
2b8760100e1de6 Lv Zheng       2015-04-13  187  typedef u64 acpi_io_address;
2b8760100e1de6 Lv Zheng       2015-04-13  188  typedef u64 acpi_physical_address;
2b8760100e1de6 Lv Zheng       2015-04-13  189  
2b8760100e1de6 Lv Zheng       2015-04-13  190  #endif				/* ACPI_32BIT_PHYSICAL_ADDRESS */
2b8760100e1de6 Lv Zheng       2015-04-13  191  
defba1d8f233c0 Bob Moore      2005-12-16  192  #define ACPI_MAX_PTR                    ACPI_UINT32_MAX
defba1d8f233c0 Bob Moore      2005-12-16  193  #define ACPI_SIZE_MAX                   ACPI_UINT32_MAX
defba1d8f233c0 Bob Moore      2005-12-16  194  
defba1d8f233c0 Bob Moore      2005-12-16  195  #else
^1da177e4c3f41 Linus Torvalds 2005-04-16  196  
59fa85057e12ff Bob Moore      2007-02-02  197  /* ACPI_MACHINE_WIDTH must be either 64 or 32 */
^1da177e4c3f41 Linus Torvalds 2005-04-16  198  
defba1d8f233c0 Bob Moore      2005-12-16 @199  #error unknown ACPI_MACHINE_WIDTH
defba1d8f233c0 Bob Moore      2005-12-16  200  #endif

^1da177e4c3f41 Linus Torvalds 2005-04-16 201

Signature · 2 lines

0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki