History log of /linux-6.15/include/acpi/actypes.h (Results 1 – 25 of 210)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


123456789