From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757818AbdJQH1J (ORCPT ); Tue, 17 Oct 2017 03:27:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:33155 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755303AbdJQH1I (ORCPT ); Tue, 17 Oct 2017 03:27:08 -0400 Date: Tue, 17 Oct 2017 09:27:02 +0200 From: Jean Delvare To: Ard Biesheuvel Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] firmware: dmi: handle missing DMI data gracefully Message-ID: <20171017092702.306edb18@endymion> In-Reply-To: <20171012195937.24817-1-ard.biesheuvel@linaro.org> References: <20171012195937.24817-1-ard.biesheuvel@linaro.org> Organization: SUSE Linux X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ard, On Thu, 12 Oct 2017 20:59:37 +0100, Ard Biesheuvel wrote: > Currently, when booting a kernel with DMI support on a platform that has > no DMI tables, the following output is emitted into the kernel log: > > [ 0.128818] DMI not present or invalid. > ... > [ 1.306659] dmi: Firmware registration failed. > ... > [ 2.908681] dmi-sysfs: dmi entry is absent. > > The first one is a pr_info(), but the subsequent ones are pr_err()s that > complain about a condition that is not really an error to begin with. > > So let's clean this up, and give up silently if dma_available is not set. On the principle I agree, but you'll have to come up with an implementation that links successfully: ERROR: "dmi_available" [drivers/firmware/dmi-sysfs.ko] undefined! scripts/Makefile.modpost:91: recipe for target '__modpost' failed make[1]: *** [__modpost] Error 1 Makefile:1216: recipe for target 'modules' failed make: *** [modules] Error 2 The reason is that dmi_available is not exported. The obvious solution is to export it. Or maybe just turn the error message into a debug message and assume the only reason it may reasonably happen is because dmi isn't available in the first place. If dmi_kobj is missing for any other reason then there's a much more important problem to solve anyway. > Signed-off-by: Ard Biesheuvel > --- > drivers/firmware/dmi-sysfs.c | 3 +++ > drivers/firmware/dmi_scan.c | 6 ++---- > 2 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c > index d5de6ee8466d..3a264cbbb5a6 100644 > --- a/drivers/firmware/dmi-sysfs.c > +++ b/drivers/firmware/dmi-sysfs.c > @@ -651,6 +651,9 @@ static int __init dmi_sysfs_init(void) > int error; > int val; > > + if (!dmi_available) > + return 0; > + > if (!dmi_kobj) { > pr_err("dmi-sysfs: dmi entry is absent.\n"); > error = -ENODATA; > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c > index 783041964439..17a7425063c2 100644 > --- a/drivers/firmware/dmi_scan.c > +++ b/drivers/firmware/dmi_scan.c > @@ -715,10 +715,8 @@ static int __init dmi_init(void) > u8 *dmi_table; > int ret = -ENOMEM; > > - if (!dmi_available) { > - ret = -ENODATA; > - goto err; > - } > + if (!dmi_available) > + return 0; > > /* > * Set up dmi directory at /sys/firmware/dmi. This entry should stay -- Jean Delvare SUSE L3 Support