linux-kernel - Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180313064334.GA1743@light.dominikbrodowski.net>
Date:   Tue, 13 Mar 2018 07:43:34 +0100
From:   Dominik Brodowski <linux@...inikbrodowski.net>
To:     Mario.Limonciello@...l.com, Darren Hart <dvhart@...radead.org>
Cc:     platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

On Tue, Mar 13, 2018 at 06:12:04AM +0000, Mario.Limonciello@...l.com wrote:
> As long as they're ready before dell-laptop's initialization which uses
> late_initcall that should be fine.
> 
> Am I correct to presume you're going to propose a patch you can test and
> confirm your hypothesis rather than Darren reverting my patch to bring
> them together?

Thanks for the input; a draft patch (which works fine on my system) is
attached below.

On Mon, Mar 12, 2018 at 11:32:13PM -0700, Darren Hart wrote:
> There is one other caveat, which you'll find documented in
> dell-laptop.c, namely that dell-laptop needs to init after dell-rbtn
> (I'm starting to appreciate the monolithic thinkpad-acpi driver).
> 
> We need things to init in this order (items on the same line have no
> dependency):
> 
> 1. DCDBAS, ACPI_WMI
> 2. DELL_SMBIOS, DELL_RBTN
> 3. DELL_LAPTOP, DELL_WMI
> 
> Currently:
> subsys_initcall: ACPI_WMI, DELL_SMBIOS
> module_init: DCDBAS, DELL_WMI
> late_initcall: DELL_LAPTOP
> 
> From a quick naive glance, it appears as though we might be able to
> address this as follows:
> 
> subsys_initcall: DCDBAS, ACPI_WMI
> module_init: DELL_SMBIOS, DELL_RBTN
> late_initcall: DELL_LAPTOP, DELL_WMI

Hmmm. I do not yet understand why you propose to

a) advance the DCDBAS initialization to subsys_initcall, as only DELL_LAPTOP
   (running as a late_initcall) requires it to be up and running, and

b) delay DELL_WMI to late_initcall, as it can safely be initialized as long
   as ACPI_WMI is ready.

What do I miss?

Attached patch *seems* to work fine on my system.

Thanks,
	Dominik

----
From: Dominik Brodowski <linux@...inikbrodowski.net>
Date: Tue, 13 Mar 2018 07:27:41 +0100
Subject: [PATCH] platform/x86: dell-smbios: wait for WMI initialization

If DELL_SMBIOS_WMI is enabled, the combined dell-smbios driver
needs to wait for ACPI_WMI to be initialized, which occurs at the
subsys_initcall() level. As the dell-smbios driver only needs to
be up and running by the time the dell-laptop module is initialized,
which occurs at the late_initcall() level, it is sufficient to
initialize the dell-smbios driver at the default device_initcall()
level.

Fixes: 25d47027e100 ("platform/x86: dell-smbios: Link all dell-smbios-* modules together")
Signed-off-by: Dominik Brodowski <linux@...inikbrodowski.net>

diff --git a/drivers/platform/x86/dell-smbios-base.c b/drivers/platform/x86/dell-smbios-base.c
index 5bcf8a18f785..2485c80a9fdd 100644
--- a/drivers/platform/x86/dell-smbios-base.c
+++ b/drivers/platform/x86/dell-smbios-base.c
@@ -637,7 +637,7 @@ static void __exit dell_smbios_exit(void)
 	mutex_unlock(&smbios_mutex);
 }

-subsys_initcall(dell_smbios_init);
+module_init(dell_smbios_init);
 module_exit(dell_smbios_exit);

 MODULE_AUTHOR("Matthew Garrett <mjg@...hat.com>");