From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa@kernel.org>
Cc: Hector Martin <marcan@marcan.st>,
Heiner Kallweit <hkallweit1@gmail.com>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3] i2c: i801: Safely share SMBus with BIOS/ACPI
Date: Tue, 30 Nov 2021 10:26:08 +0100 [thread overview]
Message-ID: <20211130102608.57e2171d@endymion> (raw)
In-Reply-To: <YaSWx7ldFfbCmrK3@kunai>
On Mon, 29 Nov 2021 10:00:55 +0100, Wolfram Sang wrote:
> On Sat, Jun 26, 2021 at 02:41:13PM +0900, Hector Martin wrote:
> > The i801 controller provides a locking mechanism that the OS is supposed
> > to use to safely share the SMBus with ACPI AML or other firmware.
> >
> > Previously, Linux attempted to get out of the way of ACPI AML entirely,
> > but left the bus locked if it used it before the first AML access. This
> > causes AML implementations that *do* attempt to safely share the bus
> > to time out if Linux uses it first; notably, this regressed ACPI video
> > backlight controls on 2015 iMacs after 01590f361e started instantiating
> > SPD EEPROMs on boot.
> >
> > Commit 065b6211a8 fixed the immediate problem of leaving the bus locked,
> > but we can do better. The controller does have a proper locking mechanism,
> > so let's use it as intended. Since we can't rely on the BIOS doing this
> > properly, we implement the following logic:
> >
> > - If ACPI AML uses the bus at all, we make a note and disable power
> > management. The latter matches already existing behavior.
> > - When we want to use the bus, we attempt to lock it first. If the
> > locking attempt times out, *and* ACPI hasn't tried to use the bus at
> > all yet, we cautiously go ahead and assume the BIOS forgot to unlock
> > the bus after boot. This preserves existing behavior.
> > - We always unlock the bus after a transfer.
> > - If ACPI AML tries to use the bus (except trying to lock it) while
> > we're in the middle of a transfer, or after we've determined
> > locking is broken, we know we cannot safely share the bus and give up.
> >
> > Upon first usage of SMBus by ACPI AML, if nothing has gone horribly
> > wrong so far, users will see:
> >
> > i801_smbus 0000:00:1f.4: SMBus controller is shared with ACPI AML. This seems safe so far.
> >
> > If locking the SMBus times out, users will see:
> >
> > i801_smbus 0000:00:1f.4: BIOS left SMBus locked
> >
> > And if ACPI AML tries to use the bus concurrently with Linux, or it
> > previously used the bus and we failed to subsequently lock it as
> > above, the driver will give up and users will get:
> >
> > i801_smbus 0000:00:1f.4: BIOS uses SMBus unsafely
> > i801_smbus 0000:00:1f.4: Driver SMBus register access inhibited
> >
> > This fixes the regression introduced by 01590f361e, and further allows
> > safely sharing the SMBus on 2015 iMacs. Tested by running `i2cdump` in a
> > loop while changing backlight levels via the ACPI video device.
> >
> > Fixes: 01590f361e ("i2c: i801: Instantiate SPD EEPROMs automatically")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Hector Martin <marcan@marcan.st>
>
> Jean, Heiner, what do we do with this topic?
I like the idea, I need to give it a try and review the code.
--
Jean Delvare
SUSE L3 Support
next prev parent reply other threads:[~2021-11-30 9:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-26 5:41 [PATCH v3] i2c: i801: Safely share SMBus with BIOS/ACPI Hector Martin
2021-11-29 9:00 ` Wolfram Sang
2021-11-30 9:26 ` Jean Delvare [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2021-12-17 0:31 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
2022-01-08 3:47 ` Hector Martin
2022-12-13 15:10 David Oberhollenzer
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=20211130102608.57e2171d@endymion \
--to=jdelvare@suse.de \
--cc=hkallweit1@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=stable@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.