| 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
| ||
|
Message-ID: <CAMcCCgR=wt8XrEMCGPvSx1BVa=ZxrQseE-HG0HLD5VG9QmMqMQ@mail.gmail.com>
Date: Thu, 2 Apr 2020 13:16:06 -0400
From: Tom Hebb <tommyhebb@...il.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org
Subject: Re: [PATCH] hwmon: (dell-smm) Use one DMI match for all XPS models
Thanks for the quick review!
On Thu, Apr 2, 2020 at 2:15 AM Guenter Roeck <linux@...ck-us.net> wrote:
>
> On 4/1/20 9:02 PM, Thomas Hebb wrote:
> > Currently, each new XPS has to be added manually for module autoloading
> > to work. Since fan multiplier autodetection should work fine on all XPS
> > models, just match them all with one block like is done for Precision
> > and Studio.
> >
> > The only match we replace that doesn't already use autodetection is
> > "XPS13" which, according to Google, only matches the XPS 13 9333. (All
> > other XPS 13 models have "XPS" as its own word, surrounded by spaces.)
> > According to the thread at [1], autodetection works for the XPS 13 9333,
> > meaning this shouldn't regress it. I do not own one to confirm with,
> > though.
> >
> > Tested on an XPS 13 9350 and confirmed the module now autoloads and
> > reports reasonable-looking data. I am using BIOS 1.12.2 and do not see
> > any freezes when querying fan speed.
> >
> > [1] https://lore.kernel.org/patchwork/patch/525367/
> >
> > Signed-off-by: Thomas Hebb <tommyhebb@...il.com>
> > ---
> >
> > drivers/hwmon/dell-smm-hwmon.c | 19 ++-----------------
> > 1 file changed, 2 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
> > index d4c83009d625..c1af4c801dd8 100644
> > --- a/drivers/hwmon/dell-smm-hwmon.c
> > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > @@ -1087,14 +1087,6 @@ static const struct dmi_system_id i8k_dmi_table[] __initconst = {
> > },
> > .driver_data = (void *)&i8k_config_data[DELL_STUDIO],
> > },
> > - {
> > - .ident = "Dell XPS 13",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > - DMI_MATCH(DMI_PRODUCT_NAME, "XPS13"),
> > - },
> > - .driver_data = (void *)&i8k_config_data[DELL_XPS],
>
> So .driver_data is no longer needed for xps 13 models ? Really ?
That is my understanding, yes. As of commit 8f21d8e939b8 ("i8k:
Autodetect fan RPM multiplier"), an explicit fan_mult from driver_data
is not needed on any machine where i8k_get_fan_nominal_speed()
works. The email thread I linked from my commit message, specifically
message #13 from Gabriele Mazzotta[1], indicates that function works
on the XPS 13 9333, as it did on all other laptops tested in that thread.
The only other information in driver_data is fan_max, which defaults to
I8K_FAN_HIGH and so won't change for the XPS 13 9333.
Note that the version of the autodetection code which actually
landed[2] (which, coincidentally, was part of the same series
containing your initial XPS 13 support) fixed the bugs mentioned
in [1] and properly tries i8k_get_fan_nominal_speed() for all fans.
[1] https://lore.kernel.org/patchwork/patch/525367/#708707
[2] https://lore.kernel.org/patchwork/patch/532107/
>
> Guenter
>
> > - },
> > {
> > .ident = "Dell XPS M140",
> > .matches = {
> > @@ -1104,17 +1096,10 @@ static const struct dmi_system_id i8k_dmi_table[] __initconst = {
> > .driver_data = (void *)&i8k_config_data[DELL_XPS],
> > },
> > {
> > - .ident = "Dell XPS 15 9560",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > - DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9560"),
> > - },
> > - },
> > - {
> > - .ident = "Dell XPS 15 9570",
> > + .ident = "Dell XPS",
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > - DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "XPS"),
>
> Quite frankly, I'd want to have this tested on many more models.
> I don't really want to deal with the fallout if it doesn't work
> on all xps a3 and xps 15 systems, especially since Dell doesn't
> support the BIOS interface used by this driver.
What fallout are you imagining? There are two XPS 15 models, 9560
and 9570, that were already matched, neither of which required
driver_data or were blacklisted for bad BIOS behavior., and I've tested
on a 9350 with the same result.
The worst case scenario I could imagine is that one of 9550, 9360, or
9370 has bad BIOS behavior and starts showing hiccups after this
patch. I don't think that's likely, though, given that the list of tested
models includes one from each generation, sampling across both 13
and 15. Additionally, the existing generic matches on "Studio",
"inspiron", "Latitude", "Precision", and "Vostro" indicate that we're
willing to accept the possibility of future breakage in exchange for
automatic detection of new machines.
-Tom
>
> Guenter
>
> > },
> > },
> > { }
> >
>
On Thu, Apr 2, 2020 at 2:15 AM Guenter Roeck <linux@...ck-us.net> wrote:
>
> On 4/1/20 9:02 PM, Thomas Hebb wrote:
> > Currently, each new XPS has to be added manually for module autoloading
> > to work. Since fan multiplier autodetection should work fine on all XPS
> > models, just match them all with one block like is done for Precision
> > and Studio.
> >
> > The only match we replace that doesn't already use autodetection is
> > "XPS13" which, according to Google, only matches the XPS 13 9333. (All
> > other XPS 13 models have "XPS" as its own word, surrounded by spaces.)
> > According to the thread at [1], autodetection works for the XPS 13 9333,
> > meaning this shouldn't regress it. I do not own one to confirm with,
> > though.
> >
> > Tested on an XPS 13 9350 and confirmed the module now autoloads and
> > reports reasonable-looking data. I am using BIOS 1.12.2 and do not see
> > any freezes when querying fan speed.
> >
> > [1] https://lore.kernel.org/patchwork/patch/525367/
> >
> > Signed-off-by: Thomas Hebb <tommyhebb@...il.com>
> > ---
> >
> > drivers/hwmon/dell-smm-hwmon.c | 19 ++-----------------
> > 1 file changed, 2 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c
> > index d4c83009d625..c1af4c801dd8 100644
> > --- a/drivers/hwmon/dell-smm-hwmon.c
> > +++ b/drivers/hwmon/dell-smm-hwmon.c
> > @@ -1087,14 +1087,6 @@ static const struct dmi_system_id i8k_dmi_table[] __initconst = {
> > },
> > .driver_data = (void *)&i8k_config_data[DELL_STUDIO],
> > },
> > - {
> > - .ident = "Dell XPS 13",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > - DMI_MATCH(DMI_PRODUCT_NAME, "XPS13"),
> > - },
> > - .driver_data = (void *)&i8k_config_data[DELL_XPS],
>
> So .driver_data is no longer needed for xps 13 models ? Really ?
>
> Guenter
>
> > - },
> > {
> > .ident = "Dell XPS M140",
> > .matches = {
> > @@ -1104,17 +1096,10 @@ static const struct dmi_system_id i8k_dmi_table[] __initconst = {
> > .driver_data = (void *)&i8k_config_data[DELL_XPS],
> > },
> > {
> > - .ident = "Dell XPS 15 9560",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > - DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9560"),
> > - },
> > - },
> > - {
> > - .ident = "Dell XPS 15 9570",
> > + .ident = "Dell XPS",
> > .matches = {
> > DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > - DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "XPS"),
>
> Quite frankly, I'd want to have this tested on many more models.
> I don't really want to deal with the fallout if it doesn't work
> on all xps a3 and xps 15 systems, especially since Dell doesn't
> support the BIOS interface used by this driver.
>
> Guenter
>
> > },
> > },
> > { }
> >
>
Powered by blists - more mailing lists