linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Henrie <alexh@vpitech.com>
To: Hector Martin <marcan@marcan.st>
Cc: linux-i2c@vger.kernel.org, wsa@kernel.org, jdelvare@suse.de,
	alexhenrie24@gmail.com
Subject: Re: [PATCH v3] i2c: i801: Safely share SMBus with BIOS/ACPI
Date: Tue, 4 Jan 2022 18:37:27 -0700	[thread overview]
Message-ID: <20220104183727.95caa694dea38a7ae5fc8c49@vpitech.com> (raw)
In-Reply-To: <20211220104106.e4c0e3d95145cc2f2a91c3d3@vpitech.com>

Hi Hector,

I had an idea today that you might like better. In your proposed patch
to share the SMBus with the BIOS, the kernel will lock itself out of
the SMBus if the BIOS uses it unsafely. What if we add a module
parameter to instead return -EPERM in i801_acpi_io_handler, effectively
locking the BIOS out of the SMBus instead of locking the kernel out? I
tried hacking that behavior in and so far it's working well on my
troublesome machine.

-Alex

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 8020b6b97..442eef67a 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1629,6 +1629,9 @@ i801_acpi_io_handler(u32 function, acpi_physical_address address, u32 bits,
 	mutex_lock(&priv->acpi_lock);
 
 	if (!priv->acpi_reserved && i801_acpi_is_smbus_ioport(priv, address)) {
+		mutex_unlock(&priv->acpi_lock);
+		return -EPERM;
+
 		priv->acpi_reserved = true;
 
 		dev_warn(&pdev->dev, "BIOS is accessing SMBus registers\n");

  reply	other threads:[~2022-01-05  1:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17  0:31 [PATCH v3] i2c: i801: Safely share SMBus with BIOS/ACPI Alex Henrie
2021-12-17  7:41 ` Hector Martin
2021-12-18  2:51   ` [External] " Alex Henrie
2021-12-18  3:39     ` Hector Martin
2021-12-20 17:41       ` Alex Henrie
2022-01-05  1:37         ` Alex Henrie [this message]
2022-01-08  3:47           ` Hector Martin
2022-01-18 12:53     ` [External] " Jean Delvare
  -- strict thread matches above, loose matches on Subject: below --
2022-12-13 15:10 David Oberhollenzer
2021-06-26  5:41 Hector Martin
2021-11-29  9:00 ` Wolfram Sang
2021-11-30  9:26   ` Jean Delvare
2022-01-19 20:48 ` Alex Henrie
2022-01-24 18:22 ` Alex Henrie
2022-07-20 19:21 ` Ettore Chimenti
2022-12-15 14:26 ` Jean Delvare
2022-12-15 21:09   ` Heiner Kallweit
2022-12-17 13:28   ` Hector Martin
2022-12-18 23:02     ` Jean Delvare

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=20220104183727.95caa694dea38a7ae5fc8c49@vpitech.com \
    --to=alexh@vpitech.com \
    --cc=alexhenrie24@gmail.com \
    --cc=jdelvare@suse.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=wsa@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).