From: Punit Agrawal <punit.agrawal@arm.com>
To: Borislav Petkov <bp@suse.de>
Cc: linux-acpi@vger.kernel.org, lorenzo.pieralisi@arm.com,
sudeep.holla@arm.com, linux-kernel@vger.kernel.org,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Punit Agrawal <punit.agrwal@arm.com>,
James Morse <james.morse@arm.com>
Subject: Re: [PATCH 2/3] GHES: Move memory initialisation to ghes_probe()
Date: Tue, 15 Aug 2017 11:10:05 +0100 [thread overview]
Message-ID: <87o9rhp2f6.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <20170814192256.56zoo5hgbyake25b@pd.tnic> (Borislav Petkov's message of "Mon, 14 Aug 2017 21:22:56 +0200")
Hi Boris,
Borislav Petkov <bp@suse.de> writes:
> On Tue, Aug 01, 2017 at 02:36:07PM +0100, Punit Agrawal wrote:
>> During the driver init, the ghes driver initialises some data structures
>
> Let's stick to "GHES" in capital letters everywhere.
>
>> which are only used if a GHES platform device is probed. Similarly, the
>> init function also checks for support for firmware first mode.
>>
>> Create a function, ghes_common_init(), that performs the initialisations
>> and checks that are currently performed on driver init. The function is
>> called when the GHES device is probed.
>>
>> Delaying initialisation and checks until probe has the added benefit of
>> reducing driver prints on systems that do not support ACPI APEI.
>>
>> Signed-off-by: Punit Agrawal <punit.agrwal@arm.com>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: James Morse <james.morse@arm.com>
>> ---
>> drivers/acpi/apei/ghes.c | 77 +++++++++++++++++++++++++++---------------------
>> 1 file changed, 43 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 007b38abcb34..befb18338acb 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -1088,12 +1088,53 @@ static inline void ghes_nmi_init_cxt(void)
>> }
>> #endif /* CONFIG_HAVE_ACPI_APEI_NMI */
>>
>> +static int ghes_common_init(void)
>> +{
>> + int rc;
>> + static bool initialised;
>> +
>> + if (initialised)
>> + return 0;
>
> Can't say that I like it. Especially for this "initialised" thing, which
> practically says that this code doesn't conceptually belong here because
> we have to explicitly force it to execute it only once. Even though we
> have execute-once path in ghes_init().
I can see your point. My rationale for the change was that the allocated
resources are only ever useful if there is an actual GHES device in the
system - which we can't know until we hit probe.
In the absence of any GHES entries these are wasted.
>
> What would be much better IMHO is if ghes_init() checked for some APEI
> table which is missing on your system and exited early. That would save
> us all the trouble and solve the situation properly ...
The system does not provide the Hardware Error Source Table (HEST) which
is checked in the hest driver (drivers/acpi/apei/hest.c).
I think I'll go with your original suggestion to change hest_disable
from a boolean to something with more states. Re-checking for the HEST
table again feels like duplication.
Makes sense?
Thanks for taking a look at the patches.
Punit
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2017-08-15 10:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-01 13:36 [PATCH 0/3] Refactor GHES to better support non-APEI systems Punit Agrawal
2017-08-01 13:36 ` [PATCH 1/3] GHES: Expand the estatus pool in ghes_estatus_pool_init() Punit Agrawal
2017-08-01 13:36 ` [PATCH 2/3] GHES: Move memory initialisation to ghes_probe() Punit Agrawal
2017-08-01 14:04 ` Punit Agrawal
2017-08-14 19:22 ` Borislav Petkov
2017-08-15 10:10 ` Punit Agrawal [this message]
2017-08-15 8:35 ` Borislav Petkov
2017-08-15 10:31 ` Punit Agrawal
2017-08-15 10:56 ` Borislav Petkov
2017-08-01 13:36 ` [PATCH 3/3] ACPI / APEI: HEST: Don't set hest_disable if table not found Punit Agrawal
2017-08-09 9:24 ` [PATCH 0/3] Refactor GHES to better support non-APEI systems Punit Agrawal
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=87o9rhp2f6.fsf@e105922-lin.cambridge.arm.com \
--to=punit.agrawal@arm.com \
--cc=bp@suse.de \
--cc=james.morse@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=punit.agrwal@arm.com \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.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