Date: Thu, 20 Jul 2017 13:17:32 +0200
From: Borislav Petkov <bp@suse.de>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: linux-kernel@vger.kernel.org, lorenzo.pieralisi@arm.com,
        sudeep.holla@arm.com, linux-acpi@vger.kernel.org,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot
Message-ID: <20170720111732.GC18515@nazgul.tnic>
References: <20170720110402.15313-1-punit.agrawal@arm.com>
 <20170720110402.15313-4-punit.agrawal@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170720110402.15313-4-punit.agrawal@arm.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 999
Lines: 33

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.

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.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--