mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Giovanni Mascellani <gio@debian.org>
To: "Pali Rohár" <pali.rohar@gmail.com>,
	"Guenter Roeck" <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>,
	linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hwmon: (dell-smm-hwmon) Disable BIOS fan control on SET_FAN
Date: Fri, 15 Nov 2019 10:51:48 +0100	[thread overview]
Message-ID: <7ea74678-59e4-2c23-6744-6d0b2eff0a67@debian.org> (raw)
In-Reply-To: <20191114215154.hze2avicv7pwiksp@pali>


[-- Attachment #1.1: Type: text/plain, Size: 1356 bytes --]

Hi,

Il 14/11/19 22:51, Pali Rohár ha scritto:
> This is model or BIOS specific. For example on E6440 are used 0x34a3 /
> 0x35a3 SMM calls. Because of these platform specific problems we have
> never incorporated this patch into mainline kernel.

Would it be sensible to use a dmi_system_id table to discriminate
between the known models and choose the right commands? Of course we
wouldn't know the complete table at the beginning, but it can be filled
as unknown models are reported.

As a matter of facts, testing your patch I discovered that 0x34a3 /
0x35a3 work on my system as well (Dell Precision 5530). Do you know
systems on which other codes only are known to work?

> Also note that userspace can issue those SMM commands on its own (via
> sys_iopl or sys_ioperm), fully bypassing such "protection" proposed in
> this new patch.

Yes, I know, but this is incompatible with Secure Boot, so I believe
that this feature should go in the kernel module, and userspace should
eventually stop doing direct requests and rely on the module. Isn't
userspace sidestepping the kernel in this way already assumed to take
their own responsibilities, much like userspace writing random things to
/dev/mem?

Thanks, Giovanni.
-- 
Giovanni Mascellani <g.mascellani@gmail.com>
Postdoc researcher - Université Libre de Bruxelles


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2019-11-15 10:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14 21:14 Giovanni Mascellani
2019-11-14 21:39 ` Guenter Roeck
2019-11-14 21:51   ` Pali Rohár
2019-11-15  9:51     ` Giovanni Mascellani [this message]
2019-11-15 11:29       ` Pali Rohár
2019-11-15 13:44         ` Giovanni Mascellani
2019-11-15 14:36           ` Pali Rohár
2019-11-15 14:46             ` Guenter Roeck
2019-11-15 19:10               ` Giovanni Mascellani
2019-11-15  7:12 ` kbuild test robot
2019-11-15  8:19 ` kbuild test robot
2019-11-16 15:03 ` Pali Rohár
2019-11-16 17:14   ` Giovanni Mascellani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ea74678-59e4-2c23-6744-6d0b2eff0a67@debian.org \
    --to=gio@debian.org \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pali.rohar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®