|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6 |
|
| #
dd067afe |
| 24-Apr-2024 |
Armin Wolf <[email protected]> |
ACPICA: Add support for Windows 11 22H2 _OSI string
ACPICA commit f56218c4e4dc1d1f699662d0726ad9e7a0d58548
See: https://github.com/microsoft_docs/windows-driver-docs/commit/be9d1c211adf8fabe5a43de7
ACPICA: Add support for Windows 11 22H2 _OSI string
ACPICA commit f56218c4e4dc1d1f699662d0726ad9e7a0d58548
See: https://github.com/microsoft_docs/windows-driver-docs/commit/be9d1c211adf8fabe5a43de71c034b1b6d7372de
Link: https://github.com/acpica/acpica/commit/f56218c4 Signed-off-by: Armin Wolf <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3 |
|
| #
8e41e0a5 |
| 21-Apr-2023 |
Linus Torvalds <[email protected]> |
Revert "ACPICA: Events: Support fixed PCIe wake event"
This reverts commit 5c62d5aab8752e5ee7bfbe75ed6060db1c787f98.
This broke wake-on-lan for multiple people, and for much too long.
Link: https:
Revert "ACPICA: Events: Support fixed PCIe wake event"
This reverts commit 5c62d5aab8752e5ee7bfbe75ed6060db1c787f98.
This broke wake-on-lan for multiple people, and for much too long.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217069 Link: https://lore.kernel.org/all/[email protected]/ Link: https://github.com/acpica/acpica/pull/866 Cc: Rafael J. Wysocki <[email protected]> Cc: Jianmin Lv <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Bob Moore <[email protected]> Cc: [email protected] # 6.2 Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v6.3-rc7, v6.3-rc6 |
|
| #
11132ad0 |
| 05-Apr-2023 |
Kees Cook <[email protected]> |
ACPICA: Introduce ACPI_FLEX_ARRAY
ACPICA commit e73b227e8e475c20cc394f237ea35d592fdf9ec3
In order to enable using -fstrict-flex-arrays with GCC and Clang in the Linux kernel, each trailing dynamica
ACPICA: Introduce ACPI_FLEX_ARRAY
ACPICA commit e73b227e8e475c20cc394f237ea35d592fdf9ec3
In order to enable using -fstrict-flex-arrays with GCC and Clang in the Linux kernel, each trailing dynamically sized array must be defined as proper C99 "flexible array members" (FAM). Unfortunately, ACPICA has a bunch of technical debt, dating back to before even the GNU extension of 0-length arrays, meaning the code base has many 1-element and 0-length arrays defined at the end of structures that should actually be FAMs.
One limitation of the C99 FAM specification is the accidental requirement that they cannot be in unions or alone in structs. There is no real-world reason for this, though, and, actually, the existing GNU extension permits this for 0-length arrays (which get treated as FAMs).
Add the ACPI_FLEX_ARRAY() helper macro to work around this requirement so that FAMs can be defined in unions or alone in structs. Since this behavior still depends on GNU extensions, keep the macro specific to GCC (and Clang) builds. In this way, MSVC will continue to use 0-length arrays (since it does not support the union work-around). When MSVC grows support for this in the future, the macro can be updated.
Link: https://github.com/acpica/acpica/commit/e73b227e Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
612c2932 |
| 05-Apr-2023 |
Bob Moore <[email protected]> |
ACPICA: Update all copyrights/signons to 2023
ACPICA commit 25bddd1824b1e450829468a64bbdcb38074ba3d2
Copyright updates to 2023.
Link: https://github.com/acpica/acpica/commit/25bddd18 Signed-off-by
ACPICA: Update all copyrights/signons to 2023
ACPICA commit 25bddd1824b1e450829468a64bbdcb38074ba3d2
Copyright updates to 2023.
Link: https://github.com/acpica/acpica/commit/25bddd18 Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
9737ff46 |
| 05-Apr-2023 |
Pedro Falcato <[email protected]> |
ACPICA: acpisrc: Add missing tables to astable
ACPICA commit d4a2c93198cdd9c6f4a83798345851fee96d5ca5
Also renames struct acpi_data_table_mapping's struct to struct acpi_data_table_mapping, just so
ACPICA: acpisrc: Add missing tables to astable
ACPICA commit d4a2c93198cdd9c6f4a83798345851fee96d5ca5
Also renames struct acpi_data_table_mapping's struct to struct acpi_data_table_mapping, just so conversion goes smoothly.
Link: https://github.com/acpica/acpica/commit/d4a2c931 Signed-off-by: Pedro Falcato <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3 |
|
| #
ee64b827 |
| 27-Oct-2022 |
Sudeep Holla <[email protected]> |
ACPICA: Add support for FFH Opregion special context data
ACPICA commit fad527b6e76babc7527c41325bfbef6bd1a1132b
FFH(Fixed Function Hardware) Opregion is approved to be added in ACPI 6.5 via code f
ACPICA: Add support for FFH Opregion special context data
ACPICA commit fad527b6e76babc7527c41325bfbef6bd1a1132b
FFH(Fixed Function Hardware) Opregion is approved to be added in ACPI 6.5 via code first approach [1]. It requires special context data similar to GPIO and Generic Serial Bus as it needs to know platform specific offset and length.
Add support for the special context data needed by FFH Opregion.
FFH op_region enables advanced use of FFH on some architectures. For example, it could be used to easily proxy AML code to architecture-specific behavior (to ensure it is OS initiated)
Actual behavior of FFH is ofcourse architecture specific and depends on the FFH bindings. The offset and length could have arch specific meaning or usage.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3598 # [1] Link: https://github.com/acpica/acpica/commit/fad527b6 Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
5c62d5aa |
| 27-Oct-2022 |
Huacai Chen <[email protected]> |
ACPICA: Events: Support fixed PCIe wake event
ACPICA commit 32d875705c8ee8f99fd8b78dbed48633486a7640
Some chipsets (such as Loongson's LS7A) support fixed pcie wake event which is defined in the PM
ACPICA: Events: Support fixed PCIe wake event
ACPICA commit 32d875705c8ee8f99fd8b78dbed48633486a7640
Some chipsets (such as Loongson's LS7A) support fixed pcie wake event which is defined in the PM1 block(related description can be found in 4.8.4.1.1 PM1 Status Registers, 4.8.4.2.1 PM1 Control Registers and 5.2.9 Fixed ACPI Description Table (FADT)), so we add code to handle it.
Link: https://uefi.org/specifications/ACPI/6.4/ Link: https://github.com/acpica/acpica/commit/32d87570 Co-developed-by: Jianmin Lv <[email protected]> Signed-off-by: Jianmin Lv <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3 |
|
| #
45882a81 |
| 11-Apr-2022 |
Bob Moore <[email protected]> |
ACPICA: Removed some tabs and // comments
ACPICA commit 0914618b553d6f3366e568409cebf2656891ca69
Automated cleanup; No functional changes.
Link: https://github.com/acpica/acpica/commit/0914618b Si
ACPICA: Removed some tabs and // comments
ACPICA commit 0914618b553d6f3366e568409cebf2656891ca69
Automated cleanup; No functional changes.
Link: https://github.com/acpica/acpica/commit/0914618b Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
487ea80a |
| 11-Apr-2022 |
Bob Moore <[email protected]> |
ACPICA: Update copyright notices to the year 2022
ACPICA commit 738d7b0726e6c0458ef93c0a01c0377490888d1e
Affects all source modules and utility signons.
Link: https://github.com/acpica/acpica/comm
ACPICA: Update copyright notices to the year 2022
ACPICA commit 738d7b0726e6c0458ef93c0a01c0377490888d1e
Affects all source modules and utility signons.
Link: https://github.com/acpica/acpica/commit/738d7b07 Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
62b32fd9 |
| 11-Apr-2022 |
Mario Limonciello <[email protected]> |
ACPICA: Add support for the Windows 11 _OSI string
ACPICA commit f2e9fb8345b9146a67f8c63474b65ccfc06d962a
See https://github.com/microsoft_docs/windows-driver-docs/commit/a061e31fd77c20cc8e6eb0234e
ACPICA: Add support for the Windows 11 _OSI string
ACPICA commit f2e9fb8345b9146a67f8c63474b65ccfc06d962a
See https://github.com/microsoft_docs/windows-driver-docs/commit/a061e31fd77c20cc8e6eb0234e5d3a83e417f48
Link: https://github.com/acpica/acpica/commit/f2e9fb83 Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1 |
|
| #
ae57857b |
| 11-Jan-2022 |
Rafael J. Wysocki <[email protected]> |
ACPICA: Use uintptr_t and offsetof() in Linux kernel builds
To avoid "performing pointer subtraction with a null pointer has undefined behavior" compiler warnings, use uintptr_t and offsetof() that
ACPICA: Use uintptr_t and offsetof() in Linux kernel builds
To avoid "performing pointer subtraction with a null pointer has undefined behavior" compiler warnings, use uintptr_t and offsetof() that are always available during Linux kernel builds to define acpi_uintptr_t and the ACPI_TO_INTEGER() and ACPI_OFFSET() macros.
Based on earlier proposal from Arnd Bergmann.
Link: https://lore.kernel.org/linux-acpi/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]>
show more ...
|
|
Revision tags: v5.16, v5.16-rc8, v5.16-rc7 |
|
| #
0acf24ad |
| 22-Dec-2021 |
Sudeep Holla <[email protected]> |
ACPICA: Add support for PCC Opregion special context data
ACPICA commit 55526e8a6133cbf5a9cc0fb75a95dbbac6eb98e6
PCC Opregion added in ACPIC 6.3 requires special context data similar to GPIO and Ge
ACPICA: Add support for PCC Opregion special context data
ACPICA commit 55526e8a6133cbf5a9cc0fb75a95dbbac6eb98e6
PCC Opregion added in ACPIC 6.3 requires special context data similar to GPIO and Generic Serial Bus as it needs to know the internal PCC buffer and its length as well as the PCC channel index when the opregion handler is being executed by the OSPM.
Lets add support for the special context data needed by PCC Opregion.
Link: https://github.com/acpica/acpica/commit/55526e8a Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
339651be |
| 22-Dec-2021 |
Jessica Clarke <[email protected]> |
ACPICA: Macros: Remove ACPI_PHYSADDR_TO_PTR
ACPICA commit 52abebd410945ec55afb4dd8b7150e8a39b5c960
This macro was only ever used when stuffing pointers into physical addresses and trying to later r
ACPICA: Macros: Remove ACPI_PHYSADDR_TO_PTR
ACPICA commit 52abebd410945ec55afb4dd8b7150e8a39b5c960
This macro was only ever used when stuffing pointers into physical addresses and trying to later reconstruct the pointer, which is implementation-defined as to whether that can be done. Now that all such operations are gone, the macro is unused, and should be removed to avoid such practices being reintroduced.
Link: https://github.com/acpica/acpica/commit/52abebd4 Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
ca25f92b |
| 22-Dec-2021 |
Jessica Clarke <[email protected]> |
ACPICA: Use original data_table_region pointer for accesses
ACPICA commit d9eb82bd7515989f0b29d79deeeb758db4d6529c
Currently the pointer to the table is cast to acpi_physical_address and later cast
ACPICA: Use original data_table_region pointer for accesses
ACPICA commit d9eb82bd7515989f0b29d79deeeb758db4d6529c
Currently the pointer to the table is cast to acpi_physical_address and later cast back to a pointer to be dereferenced. Whether or not this is supported is implementation-defined.
On CHERI, and thus Arm's experimental Morello prototype architecture, pointers are represented as capabilities, which are unforgeable bounded pointers, providing always-on fine-grained spatial memory safety. This means that any pointer cast to a plain integer will lose all its associated metadata, and when cast back to a pointer it will give a null-derived pointer (one that has the same metadata as null but an address equal to the integer) that will trap on any dereference. As a result, this is an implementation where acpi_physical_address cannot be used as a hack to store real pointers.
Thus, add a new field to struct acpi_object_region to store the pointer for table regions, and propagate it to acpi_ex_data_table_space_handler via the region context, to use a more portable implementation that supports CHERI.
Link: https://github.com/acpica/acpica/commit/d9eb82bd Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
f81bdeaf |
| 22-Dec-2021 |
Mark Langsdorf <[email protected]> |
ACPICA: actypes.h: Expand the ACPI_ACCESS_ definitions
ACPICA commit bc02c76d518135531483dfc276ed28b7ee632ce1
The current ACPI_ACCESS_*_WIDTH defines do not provide a way to test that size is small
ACPICA: actypes.h: Expand the ACPI_ACCESS_ definitions
ACPICA commit bc02c76d518135531483dfc276ed28b7ee632ce1
The current ACPI_ACCESS_*_WIDTH defines do not provide a way to test that size is small enough to not cause an overflow when applied to a 32-bit integer.
Rather than adding more magic numbers, add ACPI_ACCESS_*_SHIFT, ACPI_ACCESS_*_MAX, and ACPI_ACCESS_*_DEFAULT #defines and redefine ACPI_ACCESS_*_WIDTH in terms of the new #defines.
This was inititally reported on Linux where a size of 102 in ACPI_ACCESS_BIT_WIDTH caused an overflow error in the SPCR initialization code.
Link: https://github.com/acpica/acpica/commit/bc02c76d Signed-off-by: Mark Langsdorf <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4 |
|
| #
3bf70bd2 |
| 01-Oct-2021 |
Mario Limonciello <[email protected]> |
ACPICA: Add support for Windows 2020 _OSI string
ACPICA commit 2dc55de56d2deac30af0b484dd1d65607eb33a9c
Link: https://github.com/microsoft_docs/windows-driver-docs/commit/5164e24985e78ef4870d7a5801
ACPICA: Add support for Windows 2020 _OSI string
ACPICA commit 2dc55de56d2deac30af0b484dd1d65607eb33a9c
Link: https://github.com/microsoft_docs/windows-driver-docs/commit/5164e24985e78ef4870d7a5801a5336104f36366 Link: https://github.com/acpica/acpica/commit/2dc55de5 Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4 |
|
| #
4441e55d |
| 15-Jan-2021 |
Bob Moore <[email protected]> |
ACPICA: Updated all copyrights to 2021
This affects all ACPICA source code modules.
ACPICA commit c570953c914437e621dd5f160f26ddf352e0d2f4
Link: https://github.com/acpica/acpica/commit/c570953c Si
ACPICA: Updated all copyrights to 2021
This affects all ACPICA source code modules.
ACPICA commit c570953c914437e621dd5f160f26ddf352e0d2f4
Link: https://github.com/acpica/acpica/commit/c570953c Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Erik Kaneda <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
| #
c1a7c2ce |
| 22-Jan-2021 |
Nick Desaulniers <[email protected]> |
ACPICA: fix -Wfallthrough
ACPICA commit 4b9135f5774caa796ddf826448811e8e7f08ef2f
GCC 7.1 gained -Wimplicit-fallthrough to warn on implicit fallthrough, as well as __attribute__((__fallthrough__)) a
ACPICA: fix -Wfallthrough
ACPICA commit 4b9135f5774caa796ddf826448811e8e7f08ef2f
GCC 7.1 gained -Wimplicit-fallthrough to warn on implicit fallthrough, as well as __attribute__((__fallthrough__)) and comments to explicitly denote that cases of fallthrough were intentional. Clang also supports this warning and statement attribute, but not the comment form.
Robert Moore provides additional context about the lint comments being removed. They were for "an old version of PC-Lint, which we don't use anymore." Drop those.
This will help us enable -Wimplicit-fallthrough throughout the Linux kernel.
Suggested-by: Robert Moore <[email protected]> Reported-by: Jon Hunter <[email protected]>
Link: https://github.com/acpica/acpica/commit/4b9135f5 Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Erik Kaneda <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9 |
|
| #
ec360131 |
| 08-Oct-2020 |
Randy Dunlap <[email protected]> |
ACPICA: Drop the repeated word "an" in a comment
ACPICA commit 9ed2c006444d1def55bc6f08164ed5d9e809c856
Link: https://github.com/acpica/acpica/commit/9ed2c006 Signed-off-by: Randy Dunlap <rdunlap@i
ACPICA: Drop the repeated word "an" in a comment
ACPICA commit 9ed2c006444d1def55bc6f08164ed5d9e809c856
Link: https://github.com/acpica/acpica/commit/9ed2c006 Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Erik Kaneda <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7 |
|
| #
10cfde5d |
| 20-Jul-2020 |
Gustavo A. R. Silva <[email protected]> |
ACPICA: Replace one-element array with flexible-array
ACPICA commit 7ba2f3d91a32f104765961fda0ed78b884ae193d
The current codebase makes use of one-element arrays in the following form:
struct some
ACPICA: Replace one-element array with flexible-array
ACPICA commit 7ba2f3d91a32f104765961fda0ed78b884ae193d
The current codebase makes use of one-element arrays in the following form:
struct something { int length; u8 data[1]; };
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); instance->length = size; memcpy(instance->data, source, size);
but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };
By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the linux codebase from now on.
This issue was found with the help of Coccinelle and audited _manually_.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Link: https://github.com/acpica/acpica/commit/7ba2f3d9 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Erik Kaneda <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.8-rc6, v5.8-rc5, v5.8-rc4 |
|
| #
b8fcd0e5 |
| 30-Jun-2020 |
Rafael J. Wysocki <[email protected]> |
ACPICA: Preserve memory opregion mappings
The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once
ACPICA: Preserve memory opregion mappings
The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once which may be problematic at least in principle (for example, it may lead to conflicts with overlapping mappings having different attributes created by drivers). It may also be wasteful, because memory opregions on some systems take up vast chunks of address space while the fields in those regions actually accessed by AML are sparsely distributed.
For this reason, a one-page "window" is mapped for a given opregion on the first memory access through it and if that "window" does not cover an address range accessed through that opregion subsequently, it is unmapped and a new "window" is mapped to replace it. Next, if the new "window" is not sufficient to acess memory through the opregion in question in the future, it will be replaced with yet another "window" and so on. That may lead to a suboptimal sequence of memory mapping and unmapping operations, for example if two fields in one opregion separated from each other by a sufficiently wide chunk of unused address space are accessed in an alternating pattern.
The situation may still be suboptimal if the deferred unmapping introduced previously is supported by the OS layer. For instance, the alternating memory access pattern mentioned above may produce a relatively long list of mappings to release with substantial duplication among the entries in it, which could be avoided if acpi_ex_system_memory_space_handler() did not release the mapping used by it previously as soon as the current access was not covered by it.
In order to improve that, modify acpi_ex_system_memory_space_handler() to preserve all of the memory mappings created by it until the memory regions associated with them go away.
Accordingly, update acpi_ev_system_memory_region_setup() to unmap all memory associated with memory opregions that go away.
Reported-by: Dan Williams <[email protected]> Tested-by: Xiang Li <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.8-rc3, v5.8-rc2, v5.8-rc1 |
|
| #
f083906f |
| 04-Jun-2020 |
Erik Kaneda <[email protected]> |
ACPICA: iASL: add new OperationRegion subtype keyword PlatformRtMechanism
ACPICA commit 2c2eefa827bd37297f5f9ca4b263fcba829aaf3f
Link: https://github.com/acpica/acpica/commit/2c2eefa8 Signed-off-by
ACPICA: iASL: add new OperationRegion subtype keyword PlatformRtMechanism
ACPICA commit 2c2eefa827bd37297f5f9ca4b263fcba829aaf3f
Link: https://github.com/acpica/acpica/commit/2c2eefa8 Signed-off-by: Erik Kaneda <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2 |
|
| #
1dade3a7 |
| 12-Feb-2020 |
Mika Westerberg <[email protected]> |
ACPICA: Introduce ACPI_ACCESS_BYTE_WIDTH() macro
Sometimes it is useful to find the access_width field value in bytes and not in bits so add a helper that can be used for this purpose.
Suggested-by
ACPICA: Introduce ACPI_ACCESS_BYTE_WIDTH() macro
Sometimes it is useful to find the access_width field value in bytes and not in bits so add a helper that can be used for this purpose.
Suggested-by: Jean Delvare <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Cc: 4.16+ <[email protected]> # 4.16+ Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6 |
|
| #
800ba7c5 |
| 10-Jan-2020 |
Bob Moore <[email protected]> |
ACPICA: All acpica: Update copyrights to 2020 Including tool signons.
ACPICA commit 8b9c69d0984067051ffbe8526f871448ead6a26b
Link: https://github.com/acpica/acpica/commit/8b9c69d0 Signed-off-by: Bo
ACPICA: All acpica: Update copyrights to 2020 Including tool signons.
ACPICA commit 8b9c69d0984067051ffbe8526f871448ead6a26b
Link: https://github.com/acpica/acpica/commit/8b9c69d0 Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Erik Kaneda <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|
|
Revision tags: v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5 |
|
| #
8696beed |
| 16-Aug-2019 |
Jung-uk Kim <jkim@free_BSD.org> |
ACPICA: Add "Windows 2019" string to _OSI support.
ACPICA commit 32fffb242800b0202986e86d9b0e16f88a23de66
Link: https://github.com/acpica/acpica/commit/32fffb24 Signed-off-by: Jung-uk Kim <jkim@fre
ACPICA: Add "Windows 2019" string to _OSI support.
ACPICA commit 32fffb242800b0202986e86d9b0e16f88a23de66
Link: https://github.com/acpica/acpica/commit/32fffb24 Signed-off-by: Jung-uk Kim <jkim@free_BSD.org> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Erik Schmauss <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
show more ...
|