[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ0PR18MB3900EC8E9BCB9EF18FE18C74A1A49@SJ0PR18MB3900.namprd18.prod.outlook.com>
Date: Fri, 24 Sep 2021 15:25:03 +0000
From: Vasyl Gomonovych <vgomonovych@...vell.com>
To: Borislav Petkov <bp@...en8.de>
CC: "rafael@...nel.org" <rafael@...nel.org>,
"lenb@...nel.org" <lenb@...nel.org>,
"james.morse@....com" <james.morse@....com>,
Tony Luck <tony.luck@...el.com>,
Randy Dunlap <rdunlap@...radead.org>,
Yazen Ghannam <yazen.ghannam@....com>,
Robert Richter <rrichter@....com>,
Tom Saeger <tom.saeger@...cle.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI: APEI: Check NULL argument in exported symbol
> Looking at this more, that apei_hest_parse() thng should be made static and the export dropped.
I found apei_hest_parse() useful API to access the HEST table.
I think RAS development should increase the number of users of apei_hest_parse().
With this API we can read HEST and modify it.
Read example is to get a count of errors sources from HEST tables from the external driver and use that counter for driver data allocation.
One of write example is to patch error_status_address, if firmware change
memory layout based on boot conditions, error_status_address from hest.asl can require shift which can be recognized by driver.
Currently my RAS development underway and I recognize that legal and open way to touch HEST table is
via apei_hest_parse() from external driver.
Abstraction layer between driver main purposes and setup procedure HEST access utilize mainly apei_hest_parse().
From this perspective apei_hest_parse() become central function in access abstraction.
That is why I thought to make this check. But of course user should be responsible for own way of access.
Powered by blists - more mailing lists