From: Borislav Petkov <bp@alien8.de>
To: "Chen, Gong" <gong.chen@linux.intel.com>
Cc: tony.luck@intel.com, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH 2/8] ACPI, CPER: Update cper info
Date: Fri, 11 Oct 2013 11:06:30 +0200 [thread overview]
Message-ID: <20131011090630.GB5925@pd.tnic> (raw)
In-Reply-To: <1381473166-29303-3-git-send-email-gong.chen@linux.intel.com>
On Fri, Oct 11, 2013 at 02:32:40AM -0400, Chen, Gong wrote:
> To satisfy the necessary of following patches and make related definition
"To prepare for the following patches... " you mean?
> more clear, update some definitions about CPER. No functional changes.
>
> Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
> ---
> drivers/acpi/apei/apei-internal.h | 12 ++++-----
> drivers/acpi/apei/cper.c | 46 ++++++++++++++++-----------------
> drivers/acpi/apei/ghes.c | 54 +++++++++++++++++++--------------------
> include/acpi/actbl1.h | 14 +++++-----
> include/acpi/ghes.h | 2 +-
> 5 files changed, 64 insertions(+), 64 deletions(-)
[ … ]
> diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
> index f827f02..b2e4134 100644
> --- a/drivers/acpi/apei/cper.c
> +++ b/drivers/acpi/apei/cper.c
> @@ -5,7 +5,7 @@
> * Author: Huang Ying <ying.huang@intel.com>
> *
> * CPER is the format used to describe platform hardware error by
> - * various APEI tables, such as ERST, BERT and HEST etc.
> + * various tables, such as ERST, BERT and HEST etc.
> *
> * For more information about CPER, please refer to Appendix N of UEFI
> * Specification version 2.3.
> @@ -248,7 +248,7 @@ static const char *cper_pcie_port_type_strs[] = {
> };
>
> static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
> - const struct acpi_hest_generic_data *gdata)
> + const struct acpi_generic_data *gdata)
> {
> if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
> printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
> @@ -283,17 +283,17 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> }
>
> -static const char *apei_estatus_section_flag_strs[] = {
> +static const char *cper_estatus_section_flag_strs[] = {
"static const char * const" while at it.
Btw, please run your patches through checkpatch.pl - it does catch
things like that.
> "primary",
> "containment warning",
> "reset",
> - "threshold exceeded",
> + "error threshold exceeded",
Right, this string is user-visible so if we have to be absolutely
honest, the patch does add "functional changes" so you can remove the
statement from the commit message. :)
> "resource not accessible",
> "latent error",
> };
>
> -static void apei_estatus_print_section(
> - const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
> +static void cper_estatus_print_section(
> + const char *pfx, const struct acpi_generic_data *gdata, int sec_no)
> {
> uuid_le *sec_type = (uuid_le *)gdata->section_type;
> __u16 severity;
> @@ -302,8 +302,8 @@ static void apei_estatus_print_section(
> printk("%s""section: %d, severity: %d, %s\n", pfx, sec_no, severity,
> cper_severity_str(severity));
> printk("%s""flags: 0x%02x\n", pfx, gdata->flags);
> - cper_print_bits(pfx, gdata->flags, apei_estatus_section_flag_strs,
> - ARRAY_SIZE(apei_estatus_section_flag_strs));
> + cper_print_bits(pfx, gdata->flags, cper_estatus_section_flag_strs,
> + ARRAY_SIZE(cper_estatus_section_flag_strs));
> if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
> printk("%s""fru_id: %pUl\n", pfx, (uuid_le *)gdata->fru_id);
> if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
> @@ -339,34 +339,34 @@ err_section_too_small:
> pr_err(FW_WARN "error section length is too small\n");
> }
>
> -void apei_estatus_print(const char *pfx,
> - const struct acpi_hest_generic_status *estatus)
> +void cper_estatus_print(const char *pfx,
> + const struct acpi_generic_status *estatus)
> {
> - struct acpi_hest_generic_data *gdata;
> + struct acpi_generic_data *gdata;
> unsigned int data_len, gedata_len;
> int sec_no = 0;
> __u16 severity;
>
> - printk("%s""APEI generic hardware error status\n", pfx);
> + printk("%s""Generic Hardware Error Status\n", pfx);
Btw, what's the story with printk not using KERN_x levels in this file?
Why are we falling back to default printk levels for all printks here
and shouldn't we rather prioritize them by urgency into, say, KERN_ERR,
KERN_INFO, etc?
> severity = estatus->error_severity;
> printk("%s""severity: %d, %s\n", pfx, severity,
> cper_severity_str(severity));
> data_len = estatus->data_length;
> - gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> + gdata = (struct acpi_generic_data *)(estatus + 1);
> while (data_len >= sizeof(*gdata)) {
> gedata_len = gdata->error_data_length;
> - apei_estatus_print_section(pfx, gdata, sec_no);
> + cper_estatus_print_section(pfx, gdata, sec_no);
> data_len -= gedata_len + sizeof(*gdata);
> gdata = (void *)(gdata + 1) + gedata_len;
> sec_no++;
> }
> }
> -EXPORT_SYMBOL_GPL(apei_estatus_print);
> +EXPORT_SYMBOL_GPL(cper_estatus_print);
[ ... ]
> diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> index 0bd750e..3c62a0a 100644
> --- a/include/acpi/actbl1.h
> +++ b/include/acpi/actbl1.h
> @@ -596,7 +596,7 @@ struct acpi_hest_generic {
>
> /* Generic Error Status block */
>
> -struct acpi_hest_generic_status {
> +struct acpi_generic_status {
> u32 block_status;
> u32 raw_data_offset;
> u32 raw_data_length;
> @@ -606,15 +606,15 @@ struct acpi_hest_generic_status {
>
> /* Values for block_status flags above */
>
> -#define ACPI_HEST_UNCORRECTABLE (1)
> -#define ACPI_HEST_CORRECTABLE (1<<1)
> -#define ACPI_HEST_MULTIPLE_UNCORRECTABLE (1<<2)
> -#define ACPI_HEST_MULTIPLE_CORRECTABLE (1<<3)
> -#define ACPI_HEST_ERROR_ENTRY_COUNT (0xFF<<4) /* 8 bits, error count */
> +#define ACPI_GEN_ERR_UC (1)
> +#define ACPI_GEN_ERR_CE (1<<1)
> +#define ACPI_GEN_ERR_MULTI_UC (1<<2)
> +#define ACPI_GEN_ERR_MULTI_CE (1<<3)
Those can simply use BIT().
> +#define ACPI_GEN_ERR_COUNT_SHIFT (0xFF<<4) /* 8 bits, error count */
Other than the above nits, a patch which slims down struct names and
makes them more concrete is always welcome :)
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2013-10-11 9:06 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 6:32 Extended H/W error log driver Chen, Gong
2013-10-11 6:32 ` [PATCH 1/8] ACPI, APEI, CPER: Fix status check during error printing Chen, Gong
2013-10-11 8:50 ` Borislav Petkov
2013-10-11 6:32 ` [PATCH 2/8] ACPI, CPER: Update cper info Chen, Gong
2013-10-11 9:06 ` Borislav Petkov [this message]
2013-10-11 15:47 ` Borislav Petkov
2013-10-16 1:57 ` Joe Perches
2013-10-16 2:46 ` Chen Gong
2013-10-16 3:10 ` Joe Perches
2013-10-15 18:17 ` Naveen N. Rao
2013-10-16 1:39 ` Chen Gong
2013-10-17 12:21 ` Naveen N. Rao
2013-10-18 11:06 ` Naveen N. Rao
2013-10-11 6:32 ` [PATCH 3/8] ACPI, x86: Extended error log driver for x86 platform Chen, Gong
2013-10-11 15:24 ` Borislav Petkov
2013-10-14 3:16 ` Chen Gong
2013-10-14 10:26 ` Borislav Petkov
2013-10-14 13:03 ` Chen Gong
2013-10-14 13:28 ` Borislav Petkov
2013-10-14 16:50 ` Tony Luck
2013-10-14 17:07 ` Borislav Petkov
2013-10-14 17:16 ` Tony Luck
2013-10-11 6:32 ` [PATCH 4/8] DMI: Parse memory device (type 17) in SMBIOS Chen, Gong
2013-10-11 15:40 ` Borislav Petkov
2013-10-14 3:21 ` Chen Gong
2013-10-14 10:30 ` Borislav Petkov
2013-10-15 19:00 ` Naveen N. Rao
2013-10-11 6:32 ` [PATCH 5/8] ACPI, APEI, CPER: Add UEFI 2.4 support for memory error Chen, Gong
2013-10-11 15:41 ` Borislav Petkov
2013-10-15 17:26 ` Naveen N. Rao
2013-10-16 1:35 ` Chen Gong
2013-10-11 6:32 ` [PATCH 6/8] ACPI, APEI, CPER: Enhance memory reporting capability Chen, Gong
2013-10-11 15:49 ` Borislav Petkov
2013-10-15 19:18 ` Naveen N. Rao
2013-10-11 6:32 ` [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output format Chen, Gong
2013-10-11 16:02 ` Borislav Petkov
2013-10-14 4:55 ` Chen Gong
2013-10-14 10:36 ` Borislav Petkov
2013-10-14 17:12 ` Tony Luck
2013-10-14 18:47 ` Borislav Petkov
2013-10-14 21:03 ` Tony Luck
2013-10-14 21:50 ` Borislav Petkov
2013-10-15 9:18 ` Chen Gong
2013-10-15 10:13 ` Borislav Petkov
2013-10-15 11:28 ` Naveen N. Rao
2013-10-15 11:41 ` Naveen N. Rao
2013-10-15 12:29 ` Borislav Petkov
2013-10-15 16:42 ` Joe Perches
2013-10-15 16:49 ` Tony Luck
2013-10-15 16:56 ` Borislav Petkov
2013-10-11 6:32 ` [PATCH 8/8] ACPI / trace: Add trace interface for eMCA driver Chen, Gong
2013-10-11 7:52 ` Borislav Petkov
2013-10-11 16:14 ` Borislav Petkov
2013-10-14 7:07 ` Chen Gong
2013-10-15 16:54 ` Naveen N. Rao
2013-10-15 17:00 ` Borislav Petkov
2013-10-15 17:30 ` Naveen N. Rao
2013-10-15 17:47 ` Borislav Petkov
2013-10-16 0:43 ` Mauro Carvalho Chehab
2013-10-16 9:16 ` Borislav Petkov
2013-10-16 10:35 ` Mauro Carvalho Chehab
2013-10-16 10:42 ` Borislav Petkov
2013-10-16 11:55 ` Mauro Carvalho Chehab
2013-10-16 12:20 ` Borislav Petkov
2013-10-16 20:47 ` Luck, Tony
2013-10-17 10:34 ` Mauro Carvalho Chehab
2013-10-17 21:35 ` Luck, Tony
2013-10-16 20:35 ` Luck, Tony
2013-10-17 10:32 ` Mauro Carvalho Chehab
2013-10-16 9:50 ` Chen Gong
2013-10-16 10:49 ` Borislav Petkov
2013-10-18 11:04 ` Naveen N. Rao
2013-10-11 7:00 ` Extended H/W error log driver Joe Perches
2013-10-11 8:04 ` Borislav Petkov
2013-10-11 14:54 ` Luck, Tony
2013-10-11 15:27 ` Borislav Petkov
2013-10-14 6:49 ` Chen Gong
2013-10-14 10:55 ` Borislav Petkov
2013-10-15 4:07 ` Chen Gong
2013-10-15 9:28 ` Borislav Petkov
2013-10-15 16:15 ` Tony Luck
2013-10-15 19:10 ` Naveen N. Rao
2013-10-15 19:23 ` Borislav Petkov
2013-10-17 12:07 ` Naveen N. Rao
2013-10-17 13:04 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131011090630.GB5925@pd.tnic \
--to=bp@alien8.de \
--cc=gong.chen@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®