| Message ID | 4882553904ef48da9b12799ed7a7100c@ausx13mpc120.AMER.DELL.COM (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | Darren Hart |
| Headers | show |
On Fri, 2018-02-23 at 19:53 +0000, Mario.Limonciello@dell.com wrote: > > > Marco (CC'ed) privately emailed Pali and I to discuss an issue > > > that > > > dell-laptop > > > wasn't working properly for him and dell-smbios couldn't find a > > > backend. > > > > > > I thought at first it was an issue of the race condition recently > > > discussed but > > > it's actually a case that the distro kernel he's using compiled: > > > > > > DELL_SMBIOS > > > DELL_LAPTOP > > > > > > But didn't select DELL_SMBIOS_WMI or DELL_SMBIOS_SMM. > > > > Distros have to enable whatever they want to. > > At least in this instance I'd hypothesize it's because these are new > config > options that default to off. > > They probably had DELL_SMBIOS enabled before and carried that forward > But there was nothing to transition them to make them turn on > DELL_SMBIOS_WMI or DELL_SMBIOS_SMM. So, the driver requires now _at least_ one of the backend enabled? > > Can it be the Dell model, that survives w/o one of above or even > > both? > > The design as it exists to day is that dell-laptop needs dell-smbios > but > dell-smbios won't run unless it has a backend selected. How was it before? > Something like this maybe then to not let them even try to run dell- > smbios? Wouldn't be a regression still? P.S. See also the link I answered with to Pali.
On Friday 23 February 2018 22:17:30 Andy Shevchenko wrote: > On Fri, 2018-02-23 at 19:53 +0000, Mario.Limonciello@dell.com wrote: > > > > > Marco (CC'ed) privately emailed Pali and I to discuss an issue > > > > that > > > > dell-laptop > > > > wasn't working properly for him and dell-smbios couldn't find a > > > > backend. > > > > > > > > I thought at first it was an issue of the race condition recently > > > > discussed but > > > > it's actually a case that the distro kernel he's using compiled: > > > > > > > > DELL_SMBIOS > > > > DELL_LAPTOP > > > > > > > > But didn't select DELL_SMBIOS_WMI or DELL_SMBIOS_SMM. > > > > > > Distros have to enable whatever they want to. > > > > At least in this instance I'd hypothesize it's because these are new > > config > > options that default to off. > > > > They probably had DELL_SMBIOS enabled before and carried that forward > > But there was nothing to transition them to make them turn on > > DELL_SMBIOS_WMI or DELL_SMBIOS_SMM. > > So, the driver requires now _at least_ one of the backend enabled? Basically driver can be compiled with zero backends. But then every one request would fail and I do not see any reason why somebody want such combination on real hardware. To make dell_smbios.ko work we need *correct* backend to be loaded. For laptops >= 2017 it is needed dell_smbios_wmi.ko, For laptops <= 2007 it is needed dell_smbios_smm.ko and for remaining both should work. > > > Can it be the Dell model, that survives w/o one of above or even > > > both? > > > > The design as it exists to day is that dell-laptop needs dell-smbios > > but > > dell-smbios won't run unless it has a backend selected. > > How was it before? Before there was only dell_smbios_smm.ko and was part of dell_smbios.ko. Now when SMM API started to be deprecated and stopped to work on new laptops, it was needed to write new backend driver. > > Something like this maybe then to not let them even try to run dell- > > smbios? > > Wouldn't be a regression still? > > P.S. See also the link I answered with to Pali. >
> -----Original Message----- > From: Andy Shevchenko [mailto:andriy.shevchenko@linux.intel.com] > Sent: Friday, February 23, 2018 2:18 PM > To: Limonciello, Mario <Mario_Limonciello@Dell.com>; md@linux.it; > dvhart@infradead.org > Cc: pali.rohar@gmail.com; platform-driver-x86@vger.kernel.org > Subject: Re: dell_smbios in 4.15 and keyboard backlight > > On Fri, 2018-02-23 at 19:53 +0000, Mario.Limonciello@dell.com wrote: > > > > > Marco (CC'ed) privately emailed Pali and I to discuss an issue > > > > that > > > > dell-laptop > > > > wasn't working properly for him and dell-smbios couldn't find a > > > > backend. > > > > > > > > I thought at first it was an issue of the race condition recently > > > > discussed but > > > > it's actually a case that the distro kernel he's using compiled: > > > > > > > > DELL_SMBIOS > > > > DELL_LAPTOP > > > > > > > > But didn't select DELL_SMBIOS_WMI or DELL_SMBIOS_SMM. > > > > > > Distros have to enable whatever they want to. > > > > At least in this instance I'd hypothesize it's because these are new > > config > > options that default to off. > > > > They probably had DELL_SMBIOS enabled before and carried that forward > > But there was nothing to transition them to make them turn on > > DELL_SMBIOS_WMI or DELL_SMBIOS_SMM. > > So, the driver requires now _at least_ one of the backend enabled? Yes. > > > > Can it be the Dell model, that survives w/o one of above or even > > > both? > > > > The design as it exists to day is that dell-laptop needs dell-smbios > > but > > dell-smbios won't run unless it has a backend selected. > > How was it before? The code that's in dell-smbios-smm used to be directly in dell-smbios. It was split into backend approach so that you can choose that or choose WMI backend or both. For a true transition to how things were pre-4.15 it should have been that CONFIG_DELL_SMBIOS selected CONFIG_DELL_SMBIOS_SMM. You would have had an identical experience then after upgrade. > > > Something like this maybe then to not let them even try to run dell- > > smbios? > > Wouldn't be a regression still? > > P.S. See also the link I answered with to Pali. >
diff --git a/drivers/platform/x86/dell-smbios.c b/drivers/platform/x86/dell-smbios.c index 8541cde..71489fe 100644 --- a/drivers/platform/x86/dell-smbios.c +++ b/drivers/platform/x86/dell-smbios.c @@ -556,6 +556,11 @@ static int __init dell_smbios_init(void) const struct dmi_device *valid; int ret; +#if !defined(CONFIG_DELL_SMBIOS_WMI) && !defined(CONFIG_DELL_SMBIOS_SMM) + pr_err("Missing SMBIOS backend."); + return -ENODEV; +#endif + valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System", NULL); if (!valid) { pr_err("Unable to run on non-Dell system\n");