From patchwork Sat Mar 3 02:10:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Darren Hart X-Patchwork-Id: 10255937 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5C79C6037D for ; Sat, 3 Mar 2018 02:10:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4A95728780 for ; Sat, 3 Mar 2018 02:10:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3C5E42877F; Sat, 3 Mar 2018 02:10:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 683C928787 for ; Sat, 3 Mar 2018 02:10:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965160AbeCCCKq (ORCPT ); Fri, 2 Mar 2018 21:10:46 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:41550 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965093AbeCCCKp (ORCPT ); Fri, 2 Mar 2018 21:10:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Qu4dNnXU2kB/s040LOklPjAs/BVv9/+dnrtJ0mL3fc4=; b=p6gosOeKWSOHGDLkF8KWfAY+j RhuajA5hFoGObkmBpaNWUASTPcdCxjWXxlxGqUUZ9BcrCmksaC2aTZAbMORZW/uSixwARDr5HhiDX W7yJmcFUMcXJevKq1Alm3jEDP+xjVSBbMnb/AzU0+VIXVY2UEYx4g5o3hC+pMm/71UWyJ1fq3o8/H BqfAh8AQYrajH/OM5YIYq6t+ZjMaLeFiPymGpVkG8VIx1Bw21Enxw1IuCjs5SgNH4M8oSZAeBRr4T HjXj9q5frhWrYbvMAGUBJOoOoMwqE2NuDy0pUCCKkE+eaMUrW6SWbfMD6E3m03+CZML9vrVuHPsYa p78tPXtxw==; Received: from dvhart by bombadil.infradead.org with local (Exim 4.89 #1 (Red Hat Linux)) id 1erwdI-0007Sw-2U; Sat, 03 Mar 2018 02:10:44 +0000 Date: Fri, 2 Mar 2018 18:10:42 -0800 From: Darren Hart To: Mario Limonciello Cc: Andy Shevchenko , pali.rohar@gmail.com, LKML , platform-driver-x86@vger.kernel.org Subject: Re: [PATCH v3 3/3] platform/x86: dell-smbios: Link all dell-smbios-* modules together Message-ID: <20180303021042.GA11088@fury> References: <1519755784-2155-1-git-send-email-mario.limonciello@dell.com> <1519755784-2155-3-git-send-email-mario.limonciello@dell.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1519755784-2155-3-git-send-email-mario.limonciello@dell.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: platform-driver-x86-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: platform-driver-x86@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Feb 27, 2018 at 12:23:04PM -0600, Mario Limonciello wrote: > Some race conditions were raised due to dell-smbios and its backends > not being ready by the time that a consumer would call one of the > exported methods. > > To avoid this problem, guarantee that all initialization has been > done by linking them all together and running init for them all. > > As part of this change the Kconfig needs to be adjusted so that > CONFIG_DELL_SMBIOS_SMM and CONFIG_DELL_SMBIOS_WMI are boolean > rather than modules. > > CONFIG_DELL_SMBIOS is a visually selectable option again and both > CONFIG_DELL_SMBIOS_WMI and CONFIG_DELL_SMBIOS_SMM are optional. > > Signed-off-by: Mario Limonciello > --- > Changes from v2: > * Move rest of #ifdef out of source files > * Only compile units as necessary > > drivers/platform/x86/Kconfig | 11 ++++++++--- > drivers/platform/x86/Makefile | 4 ++-- > drivers/platform/x86/dell-smbios-base.c | 21 ++++++++++++++++++++- > drivers/platform/x86/dell-smbios-smm.c | 18 ++++-------------- > drivers/platform/x86/dell-smbios-wmi.c | 14 ++++---------- > drivers/platform/x86/dell-smbios.h | 27 ++++++++++++++++++++++++++- > 6 files changed, 64 insertions(+), 31 deletions(-) > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index 9a8f964..0c0897e 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -106,10 +106,15 @@ config ASUS_LAPTOP > If you have an ACPI-compatible ASUS laptop, say Y or M here. > > config DELL_SMBIOS > - tristate > + tristate "Dell SMBIOS driver" > + ---help--- > + This provides support for the Dell SMBIOS calling interface. > + If you have a Dell computer you should enable this option. > + > + Be sure to select at least one backend for it to work properly. > > config DELL_SMBIOS_WMI > - tristate "Dell SMBIOS calling interface (WMI implementation)" > + bool "Dell SMBIOS driver WMI support" > depends on ACPI_WMI > select DELL_WMI_DESCRIPTOR > select DELL_SMBIOS Blarg, this also violates the kconfig-language guidance for using select only for non-visible symbols with no dependencies. I have a patch that works, but I don't love it. We can remove the prompt from DELL_SMBIOS, and make DELL_SMBIOS_WMI|SMM "depend on" DELL_SMBIOS. The options just appear sort of randomly when either DELL_LAPTOP or DELL_WMI are selected - but they can default to y, which is nice. I have a subsequent patch which makes DELL_SMBIOS_WMI|SMM "depend on" DELL_LAPTOP, which makes this look a lot nicer. These just appear under DELL_LAPTOP as bool options. The problem with this approach is DELL_WMI also requires DELL_SMBIOS and DELL_WMI doesn't currently depend on DELL_LAPTOP. One option is to make it depend on DELL_LAPTOP as it seems unlikely for them to ever be used separately. I don't love this either. Thoughts? Perhaps the compromise is leave the DELL_SMBIOS prompt. This doesn't have the negative consequences the kconfig-languages is trying to guard against, and it makes it obvious what the DELL_SMBIOS_* options are - and we can still default them to y. See below. This seems like it might be the least bad option at the moment. I'll keep thinking on it a bit... From: "Darren Hart (VMware)" Date: Fri, 2 Mar 2018 17:40:32 -0800 Subject: [PATCH] platform/x86: Allow for SMBIOS backend defaults Avoid accidental configurations by setting default y for DELL_SMBIOS backends. Avoid this impacting the default build size, by making them dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is manually selected, or by DELL_LAPTOP or DELL_WMI. Signed-off-by: Darren Hart (VMware) --- drivers/platform/x86/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index e3f682c..022c837 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -115,9 +115,10 @@ config DELL_SMBIOS config DELL_SMBIOS_WMI bool "Dell SMBIOS driver WMI backend" + default y depends on ACPI_WMI select DELL_WMI_DESCRIPTOR - select DELL_SMBIOS + depends on DELL_SMBIOS ---help--- This provides an implementation for the Dell SMBIOS calling interface communicated over ACPI-WMI. @@ -128,8 +129,9 @@ config DELL_SMBIOS_WMI config DELL_SMBIOS_SMM bool "Dell SMBIOS driver SMM backend" + default y depends on DCDBAS - select DELL_SMBIOS + depends on DELL_SMBIOS ---help--- This provides an implementation for the Dell SMBIOS calling interface communicated over SMI/SMM.