Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Lyude <lyude@redhat.com>
Cc: Jean Delvare <jdelvare@suse.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	Benjamin Tissoires <btissoir@redhat.com>,
	intel-gfx@lists.freedesktop.org,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-i2c@vger.kernel.org, Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder
Date: Fri, 30 Jun 2017 13:56:50 +0300	[thread overview]
Message-ID: <20170630105650.GY629@lahna.fi.intel.com> (raw)
In-Reply-To: <20170626204009.32607-1-lyude@redhat.com>

On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote:
> There's quite a number of machines on the market, mainly Lenovo
> ThinkPads, that make the horrible mistake in their firmware of reusing
> the PCIBAR space reserved for the SMBus for things that are completely
> unrelated to the SMBus controller, such as the OpRegion used for i915.
> This is very bad and entirely evil, but with Lenovo's historically poor
> track record of fixing their firmware, it is extremely unlikely this is
> ever going to be properly fixed.
> 
> So, while it would be nice if we could just cut off the SMBus controller
> and call it a day this unfortunately breaks RMI4 mode completely for
> most of the ThinkPads. Even though this behavior is extremely wrong, for
> whatever reason sharing the PCIBAR between the OpRegion and SMBus seems
> to be just fine. Regardless however, I think it's safe to assume that
> when the BIOS accesses the PCIBAR space of the SMBus controller like
> this that it's trying to get to something else that we mapped the SMBus
> controller over.
> 
> On my X1 Carbon, this assumption appears to be correct. I've traced down
> the firmware accesses to being caused by the firmware mistakenly placing
> the SWSCI mailbox for i915 on top of the SMBus host controller region.
> And indeed, blacklisting i915 causes the firmware to never attempt to
> touch this region.
> 
> So, in order to try to workaround this and not break either SMBus or
> i915, we temporarily unmap the PCI device for the SMBus controller,
> do the thing that the firmware wanted to do, then remap the device and
> report a firmware bug.

Are the registers it tries to access separate from SMBus ones? We
already have TCO registers placed to this device starting from Skylake
so there might be something else as well.

Point here is that if the access is not to the SMBus registers we can
quirk it in the driver and let the access happen because it does not
mess our state.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx