Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935977AbdGTM30 convert rfc822-to-8bit (ORCPT ); Thu, 20 Jul 2017 08:29:26 -0400 Received: from foss.arm.com ([217.140.101.70]:53128 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935939AbdGTM3U (ORCPT ); Thu, 20 Jul 2017 08:29:20 -0400 From: Punit Agrawal To: Borislav Petkov Cc: , , , , "Rafael J. Wysocki" Subject: Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot References: <20170720110402.15313-1-punit.agrawal@arm.com> <20170720110402.15313-4-punit.agrawal@arm.com> <20170720111732.GC18515@nazgul.tnic> Date: Thu, 20 Jul 2017 13:29:17 +0100 In-Reply-To: <20170720111732.GC18515@nazgul.tnic> (Borislav Petkov's message of "Thu, 20 Jul 2017 13:17:32 +0200") Message-ID: <87d18vmgv6.fsf@e105922-lin.cambridge.arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1726 Lines: 55 Hi Borislav, Borislav Petkov writes: > On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote: >> When booting an ACPI enabled system that does not provide the hardware >> error source table (HEST), the ghes driver prints the following message >> in the kernel log - >> >> [ 3.460067] GHES: HEST is not enabled! >> >> which is not helpful. >> >> The message is also output when HEST is explicitly disabled using kernel >> command line parameter. >> >> Drop this message. While we are touching this code, also drop similar >> message when GHES is disabled using the module parameter. > > No. > > To the contrary, we want to know *why* GHES/HEST doesn't get enabled when > booting. See > > dba648300e89 ("ACPI / einj: Make error paths more talkative") > > for a good example why. einj verbosity can't be used as a model here. einj by it's definition is for development and testing. It can also be loaded as a module. > > If anything, you should do the total opposite patch and add more >printks to the error paths so that it is obvious why GHES startup >fails. As mentioned in the commit log, the platform doesn't provide the HEST (or any of the APEI tables for that matter). So it's not useful to see a message complaining that HEST is not enabled. For such platforms, this message at best adds no value and at worse gives the impression of something gone wrong during boot. I agree that where there is a genuine problem, relevant messages can help to diagnose the problem. But what's printed now doesn't fit the criteria. Hope that makes sense. Thanks, Punit > > -- Regards/Gruss, Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)