[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR01MB39758AB5AF4A67AF8278E361E3F00@BYAPR01MB3975.prod.exchangelabs.com>
Date: Wed, 10 Jul 2019 00:49:56 +0000
From: Tyler Baicar OS <baicar@...amperecomputing.com>
To: Shiju Jose <shiju.jose@...wei.com>,
Open Source Submission <patches@...erecomputing.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"james.morse@....com" <james.morse@....com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>,
"lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
"Guohanjun (Hanjun Guo)" <guohanjun@...wei.com>,
"sudeep.holla@....com" <sudeep.holla@....com>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"lenb@...nel.org" <lenb@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"bp@...en8.de" <bp@...en8.de>,
"Matteo.Carlini@....com" <Matteo.Carlini@....com>,
"Andrew.Murray@....com" <andrew.murray@....com>
Subject: Re: [PATCH RFC 1/4] ACPI/AEST: Initial AEST driver
Hello Shiju,
Thank you for the feedback!
On Thu, Jul 4, 2019 at 12:03 PM Shiju Jose <shiju.jose@...wei.com> wrote:
> >+struct ras_ext_regs {
> >+ u64 err_fr;
> >+ u64 err_ctlr;
> >+ u64 err_status;
> >+ u64 err_addr;
> >+ u64 err_misc0;
> >+ u64 err_misc1;
> >+ u64 err_misc2;
> >+ u64 err_misc3;
> err_misc2 and err_misc3 are not used. Are they for the future purpose?
Yes, these will be for future purpose once ARMv8.4 support is added. I'd like
to keep them in this structure define since that makes iterating through the
memory mapped error records easier. Regardless of ARMv8.2 or ARMv8.4 support,
each error record in memory mapped nodes are 64 bytes apart. Having these in
the structure make the structure 64 bytes long making it possible for me to
increment through error records with the increment ++ operation.
If folks don't agree with that, I can change this structure to just have a
reserved field at the end such as:
+ u64 res0[2];
or
+ u8 res0[8];
> >+ ppi_data = kcalloc(num_ppi, sizeof(struct aest_node_data *),
> >+ GFP_KERNEL);
> >+
> >+ for (i = 0; i < num_ppi; i++) {
> >+ ppi_data[i] = alloc_percpu(struct aest_node_data);
> >+ if (!ppi_data[i]) {
> >+ ret = -ENOMEM;
> >+ break;
> >+ }
> >+ }
> >+
> >+ if (ret) {
> >+ pr_err("Failed percpu allocation\n");
> >+ for (i = 0; i < num_ppi; i++)
> >+ free_percpu(ppi_data[i]);
> I think 'ppi_data' to be freed here?
Yes it should be! I'll add that in the next version.
Thanks,
Tyler
Powered by blists - more mailing lists