linux-kernel - Re: [PATCH v3 2/5] ACPI/APEI: Remove static from apei_hest

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230810231718.GA49532@bhelgaas>
Date:   Thu, 10 Aug 2023 18:17:18 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     LeoLiu-oc <LeoLiu-oc@...oxin.com>
Cc:     lenb@...nel.org, james.morse@....com, tony.luck@...el.com,
        bp@...en8.de, bhelgaas@...gle.com, robert.moore@...el.com,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, acpica-devel@...ts.linuxfoundation.org
Subject: Re: [PATCH v3 2/5] ACPI/APEI: Remove static from apei_hest_parse()

On Tue, Jul 04, 2023 at 08:05:17PM +0800, LeoLiu-oc wrote:
> From: leoliu-oc <leoliu-oc@...oxin.com>
> 
> Each dev with AER capability needs to call the apei_hest_parse function to
> match and extract register values from HEST PCIe AER structures.
> Therefore, remove static from apei_hest_parse() so that it can be called
> in another file.

Can you reword the subject line and commit log in the positive?
"Removing static" is a negative thing and it's semantically a bit too
low level -- it's clearly what the *code* does, but we can see that
from the patch, and what we want to know here is *why* it's important.
What this really does is expose apei_hest_parse() for use by other
subsystems.

Browsing the drivers/acpi commit log history, I see that Rafael adds
"()" after function names, so please do the same here (you did do that
once above, but not in the first line).

> Signed-off-by: leoliu-oc <leoliu-oc@...oxin.com>
> ---
>  drivers/acpi/apei/hest.c | 2 +-
>  include/acpi/apei.h      | 5 +++++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
> index fb839a5c480ee..fd40c035c9b2e 100644
> --- a/drivers/acpi/apei/hest.c
> +++ b/drivers/acpi/apei/hest.c
> @@ -132,7 +132,7 @@ static bool hest_match_pci(struct acpi_hest_header *hest_hdr,
>  	return false;
>  }
>  
> -static int apei_hest_parse(apei_hest_func_t func, void *data)
> +int apei_hest_parse(apei_hest_func_t func, void *data)

If this is going to exported to the PCI subsystem, I think it needs
some kernel-doc.  For example, it's important to know that it stops
parsing the HEST if func returns anything non-zero.  This is how
pci_acpi_program_hest_aer_params() knows that it got good data that
matches the device it wants.

Given the fact that apei_hest_parse_aer() fills in the struct
acpi_hest_parse_aer_info with pointers into the HEST table data, it's
also important to know that this HEST table data is persistent.

>  {
>  	struct acpi_hest_header *hest_hdr;
>  	int i, rc, len;
> diff --git a/include/acpi/apei.h b/include/acpi/apei.h
> index 8a0b2b9edbafe..f975e4fe78fcb 100644
> --- a/include/acpi/apei.h
> +++ b/include/acpi/apei.h
> @@ -37,9 +37,14 @@ typedef int (*apei_hest_func_t)(struct acpi_hest_header *hest_hdr, void *data);
>  
>  #ifdef CONFIG_ACPI_APEI
>  void __init acpi_hest_init(void);
> +int apei_hest_parse(apei_hest_func_t func, void *data);
>  int apei_hest_parse_aer(struct acpi_hest_header *hest_hdr, void *data);
>  #else
>  static inline void acpi_hest_init(void) { }
> +static inline int apei_hest_parse(apei_hest_func_t func, void *data)
> +{
> +	return -EINVAL;
> +}
>  static inline int apei_hest_parse_aer(struct acpi_hest_header *hest_hdr, void *data)
>  {
>  	return -EINVAL;
> -- 
> 2.34.1
>