[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bddaade724054711ba4682f73ec54264@ausx13mpc120.AMER.DELL.COM>
Date: Tue, 13 Mar 2018 07:07:26 +0000
From: <Mario.Limonciello@...l.com>
To: <linux@...inikbrodowski.net>, <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
> -----Original Message-----
> From: Dominik Brodowski [mailto:linux@...inikbrodowski.net]
> Sent: Tuesday, March 13, 2018 2:44 PM
> To: Limonciello, Mario <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
Actually dell-smbios itself should require this too. The SMM backend will use
it during initialization to determine if WSMT is enabled. If it's not operational
yet then we may get invalid results.
So considering this I think Darren's proposal is good to move DCDBAS to earlier.
>
> b) delay DELL_WMI to late_initcall, as it can safely be initialized as long
> as ACPI_WMI is ready.
Maybe Darren meant dell-wmi-descriptor not dell-wmi?
Otherwise I would agree that part isn't needed.
>
> What do I miss?
>
> Attached patch *seems* to work fine on my system.
At least to me, I think it's better to see
>
> 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>");
Powered by blists - more mailing lists