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] [day] [month] [year] [list]

Date:   Wed, 14 Mar 2018 01:28:54 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>
CC:     <linux@...inikbrodowski.net>,
        <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: Darren Hart [mailto:dvhart@...radead.org]
> Sent: Wednesday, March 14, 2018 5:43 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: linux@...inikbrodowski.net; 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 07:07:26AM +0000, Mario.Limonciello@...l.com wrote:
> > > -----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.
> >
> 
> Exactly.
> 
> > 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.
> 
> Like DELL_LAPTOP, DELL_WMI depends on smbios being ready, so needs to
> init after DELL_SMBIOS as well.
> 
> --

OK thanks for explaining.

Dominik,

Can you please verify if Darren's patch works for you too?

Darren,

If that patch works for Dominik, I'm fine with that for 4.16 if you keep
this series, otherwise we can retry for 4.17 and squash the various patches
together.

Thanks,