linux-kernel - Re: [PATCH v2 1/2] ACPICA: Detect FACS in reduced hardware build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gBk+vVKd1zXN7+4fX_-T-enmGMT=BD5R8CU_1C+xdQDw@mail.gmail.com>
Date: Mon, 26 Aug 2024 11:59:51 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Jiaqing Zhao <jiaqing.zhao@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Robert Moore <robert.moore@...el.com>, 
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org, 
	acpica-devel@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] ACPICA: Detect FACS in reduced hardware build

On Mon, Aug 26, 2024 at 3:10 AM Jiaqing Zhao
<jiaqing.zhao@...ux.intel.com> wrote:
>
> On 2024-08-20 22:55, Rafael J. Wysocki wrote:
> > On Mon, Aug 12, 2024 at 7:47 AM Jiaqing Zhao
> > <jiaqing.zhao@...ux.intel.com> wrote:
> >>
> >> According to Section 5.2.10 of ACPI Specification, FACS is optional
> >> in reduced hardware model. Enable the detection for "Hardware-reduced
> >> ACPI support only" build (CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y) also.
> >>
> >> Link: https://github.com/acpica/acpica/commit/ee53ed6b5452612bb44af542b68d605f8b2b1104
> >> Signed-off-by: Jiaqing Zhao <jiaqing.zhao@...ux.intel.com>
> >> ---
> >>  drivers/acpi/acpica/acglobal.h |  6 +-----
> >>  drivers/acpi/acpica/tbutils.c  |  5 +----
> >>  drivers/acpi/acpica/utxfinit.c | 24 ++++++++++++------------
> >>  include/acpi/acconfig.h        |  1 -
> >>  4 files changed, 14 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
> >> index f4c90fc99be2..309ce8efb4f6 100644
> >> --- a/drivers/acpi/acpica/acglobal.h
> >> +++ b/drivers/acpi/acpica/acglobal.h
> >> @@ -29,11 +29,7 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_dsdt_index, ACPI_INVALID_TABLE_INDEX);
> >>  ACPI_INIT_GLOBAL(u32, acpi_gbl_facs_index, ACPI_INVALID_TABLE_INDEX);
> >>  ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index, ACPI_INVALID_TABLE_INDEX);
> >>  ACPI_INIT_GLOBAL(u32, acpi_gbl_fadt_index, ACPI_INVALID_TABLE_INDEX);
> >> -
> >> -#if (!ACPI_REDUCED_HARDWARE)
> >> -ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
> >> -
> >> -#endif                         /* !ACPI_REDUCED_HARDWARE */
> >> +ACPI_INIT_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS, NULL);
> >>
> >>  /* These addresses are calculated from the FADT Event Block addresses */
> >>
> >> diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
> >> index 15fa68a5ea6e..356700349b45 100644
> >> --- a/drivers/acpi/acpica/tbutils.c
> >> +++ b/drivers/acpi/acpica/tbutils.c
> >> @@ -18,7 +18,6 @@ ACPI_MODULE_NAME("tbutils")
> >>  static acpi_physical_address
> >>  acpi_tb_get_root_table_entry(u8 *table_entry, u32 table_entry_size);
> >>
> >> -#if (!ACPI_REDUCED_HARDWARE)
> >>  /*******************************************************************************
> >>   *
> >>   * FUNCTION:    acpi_tb_initialize_facs
> >> @@ -37,8 +36,7 @@ acpi_status acpi_tb_initialize_facs(void)
> >>         struct acpi_table_facs *facs;
> >>
> >>         if (acpi_gbl_FADT.Xfacs &&
> >> -                  (!acpi_gbl_FADT.facs
> >> -                   || !acpi_gbl_use32_bit_facs_addresses)) {
> >> +           (!acpi_gbl_FADT.facs || !acpi_gbl_use32_bit_facs_addresses)) {
> >>                 (void)acpi_get_table_by_index(acpi_gbl_xfacs_index,
> >>                                               ACPI_CAST_INDIRECT_PTR(struct
> >>                                                                      acpi_table_header,
> >
> > I'm not sure how this change is related to the rest of the patch.
> >
> > It doesn't appear to be present in the original commit pointed to by
> > the Link tag.
>
> This change here is just indention fix, in original acpica, the indention is just fine.
>
> Shall I remove this change?

Yes, please.

If you send a Linux counterpart of an ACPICA change, it should not
contain any changes in addition to what was there in the original
ACPICA commit.

Thanks!