Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421AbdF3K5m (ORCPT ); Fri, 30 Jun 2017 06:57:42 -0400 Received: from mga07.intel.com ([134.134.136.100]:54119 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690AbdF3K44 (ORCPT ); Fri, 30 Jun 2017 06:56:56 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,286,1496127600"; d="scan'208";a="280584836" Date: Fri, 30 Jun 2017 13:56:50 +0300 From: Mika Westerberg To: Lyude Cc: intel-gfx@lists.freedesktop.org, "Rafael J . Wysocki" , Benjamin Tissoires , Jean Delvare , Wolfram Sang , Jean Delvare , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder Message-ID: <20170630105650.GY629@lahna.fi.intel.com> References: <20170626204009.32607-1-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170626204009.32607-1-lyude@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1954 Lines: 36 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.